From: James Simmons <hidden> Date: 2003-03-25 17:46:10
As usually I have a patch avalaible at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
drivers/video/aty/aty128fb.c | 16 +++++++---------
drivers/video/console/fbcon.c | 4 ++--
drivers/video/controlfb.c | 18 +++---------------
drivers/video/platinumfb.c | 28 ++++++++--------------------
drivers/video/radeonfb.c | 10 ++++++++++
drivers/video/softcursor.c | 2 +-
6 files changed, 31 insertions(+), 47 deletions(-)
The patch has updates for the ATI Rage 128, Control, and Platnium
framebuffer driver. The Radeon patch adds PLL times for the R* series of
cards. Memory is now safe to allocate for the software cursor and inside
fbcon. There still are issues with syncing which cause the cursor on some
systems to become corrupt sometimes.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
On Tue, Mar 25, 2003 at 05:57:18PM +0000, James Simmons wrote:
As usually I have a patch avalaible at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
drivers/video/aty/aty128fb.c | 16 +++++++---------
drivers/video/console/fbcon.c | 4 ++--
drivers/video/controlfb.c | 18 +++---------------
drivers/video/platinumfb.c | 28 ++++++++--------------------
drivers/video/radeonfb.c | 10 ++++++++++
drivers/video/softcursor.c | 2 +-
6 files changed, 31 insertions(+), 47 deletions(-)
The patch has updates for the ATI Rage 128, Control, and Platnium
framebuffer driver. The Radeon patch adds PLL times for the R* series of
cards. Memory is now safe to allocate for the software cursor and inside
fbcon. There still are issues with syncing which cause the cursor on some
systems to become corrupt sometimes.
Where can I find working "modelines" for Radeon 8500?
I have a
radeonfb: ATI Radeon 8500 QL DDR SGRAM 64 MB
I am interested in 1024x768 and 1152x864. I have tried the defaults
that come with Debian fbset (2.1-8) but I get garbled screen upon
changing the video mode. I can 'clear' the console and work more or
less normally but the viewport will be just a part of the whole
screen.
Thanks,
florin
--
"NT is to UNIX what a doughnut is to a particle accelerator."
From: James Simmons <hidden> Date: 2003-03-25 20:39:40
Where can I find working "modelines" for Radeon 8500?
I have a
radeonfb: ATI Radeon 8500 QL DDR SGRAM 64 MB
I am interested in 1024x768 and 1152x864. I have tried the defaults
that come with Debian fbset (2.1-8) but I get garbled screen upon
changing the video mode. I can 'clear' the console and work more or
less normally but the viewport will be just a part of the whole
screen.
Try using stty. I see most people will continue to use fbset so I guess I
need to patch it up to do the right thing.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-03-26 13:03:42
On Tue, 2003-03-25 at 21:50, James Simmons wrote:
Try using stty. I see most people will continue to use fbset so I guess I
need to patch it up to do the right thing.
Well, I don't like the fbdev magially picking modes like this,
those modes may just not be supported by the display. At least,
fbset allows me to setup the proper timings for 'special'
displays like iMac fixed hoziontal frequency for example.
Ultimately, we really need a "monitor" driver on top of the
fbdev that does DDC/EDID when the low level fbdev can provide
an i2c bus or EDID information via some different way and
that can be tweaked to deal with special monitors when we
know we are using these.
Ben.
From: James Simmons <hidden> Date: 2003-03-26 19:58:31
On Tue, 2003-03-25 at 21:50, James Simmons wrote:
quoted
Try using stty. I see most people will continue to use fbset so I guess I
need to patch it up to do the right thing.
Well, I don't like the fbdev magially picking modes like this,
those modes may just not be supported by the display. At least,
fbset allows me to setup the proper timings for 'special'
displays like iMac fixed hoziontal frequency for example.
Ultimately, we really need a "monitor" driver on top of the
fbdev that does DDC/EDID when the low level fbdev can provide
an i2c bus or EDID information via some different way and
that can be tweaked to deal with special monitors when we
know we are using these.
fbmon.c :-)
The code should work for PPC and I seen a patch for generic ix86 support.
No DDC stuff yet tho.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
As usually I have a patch avalaible at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
drivers/video/aty/aty128fb.c | 16 +++++++---------
drivers/video/console/fbcon.c | 4 ++--
drivers/video/controlfb.c | 18 +++---------------
drivers/video/platinumfb.c | 28 ++++++++--------------------
drivers/video/radeonfb.c | 10 ++++++++++
drivers/video/softcursor.c | 2 +-
6 files changed, 31 insertions(+), 47 deletions(-)
The patch has updates for the ATI Rage 128, Control, and Platnium
framebuffer driver. The Radeon patch adds PLL times for the R* series of
cards. Memory is now safe to allocate for the software cursor and inside
fbcon. There still are issues with syncing which cause the cursor on some
systems to become corrupt sometimes.
- data = kmalloc(size, GFP_KERNEL);
- mask = kmalloc(size, GFP_KERNEL);
+ data = kmalloc(size, GFP_ATOMIC);
+ mask = kmalloc(size, GFP_ATOMIC);
if (cursor->set & FB_CUR_SETSIZE) {
memset(data, 0xff, size);
irk, you replaced GFP_KERNEL with GFP_ATOMIC, and even unconditionally
memset the return without even bothering to check if it succeeded or
not.
--
Jens Axboe
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: James Simmons <hidden> Date: 2003-03-25 18:35:58
irk, you replaced GFP_KERNEL with GFP_ATOMIC, and even unconditionally
memset the return without even bothering to check if it succeeded or
not.
Patch is dead. I'm working on a workqueue solution now.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: Scott Robert Ladd <hidden> Date: 2003-03-26 13:52:27
James Simmons wrote:
As usually I have a patch avalaible at
The patch has updates for the ATI Rage 128, Control, and Platnium
framebuffer driver. The Radeon patch adds PLL times for the R* series of
cards. Memory is now safe to allocate for the software cursor and inside
fbcon. There still are issues with syncing which cause the cursor on some
systems to become corrupt sometimes.
From your description, this doesn't sound like these patches solve the
problem with radeonfb not detecting a DFP connected to the DVI. I posted
a message about this bug a week ago, and am more than willing to look
into fixing it myself if it isn't on your schedule.
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
From: James Simmons <hidden> Date: 2003-03-26 19:56:49
quoted
As usually I have a patch avalaible at
The patch has updates for the ATI Rage 128, Control, and Platnium
framebuffer driver. The Radeon patch adds PLL times for the R* series of
cards. Memory is now safe to allocate for the software cursor and inside
fbcon. There still are issues with syncing which cause the cursor on some
systems to become corrupt sometimes.
From your description, this doesn't sound like these patches solve the
problem with radeonfb not detecting a DFP connected to the DVI. I posted
a message about this bug a week ago, and am more than willing to look
into fixing it myself if it isn't on your schedule.
If you have the docs and teh ahrdware could you? I don't have either.
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en