Changing modes with fbset
Subsystems (2)
I've downloaded fbutils from the CVS and fixed up the source so that they work (for the most part). It reads the modedb and finds the mode I requested on the command line. But when it tries to switch my monitor looses sync and the machine hangs. I did a var.Print instead of the var.Set and the values look OK. Anyone have any ideas?
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Found it. It's a bug in fbcon.c where the rows and cols were mixed up so fbcon_resize tries to set the mode again with xres and yres reversed. Didn't happen during boot as fbcon_state_manager is registered after the console is taken over.
drivers/video/console/fbcon.c +0 -0
@@ -2261,8 +2261,8 @@
// Switch resolution size int rows, cols;
- rows = info->var.xres / vc->vc_font.height;
- cols = info->var.yres / vc->vc_font.width;
+ rows = info->var.yres / vc->vc_font.height;
+ cols = info->var.xres / vc->vc_font.width;
fbcon_resize(vc, cols, rows);
info->state |= flag;
}John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
fbdev upstream (was: Changing modes with fbset)
Quoted 4 lines · John Zielinski
Found it. It's a bug in
fbcon.cwhere the rows and cols were mixed up sofbcon_resizetries to set the mode again with xres and yres reversed. Didn't happen during boot asfbcon_state_manageris registered after the console is taken over.
Good catch. I merged that in my tree (I use a different version of the client notification mecanism though, I don't like much the version that James pushed).
Since James vanished, I intend to take the most obvious bug fixes and driver updates from his tree into mine, test them, and then submit them one by one to Andrew Morton for 2.6.x inclusion.
I do not intend, at least in a first step, to take the sysfs stuffs as the structure lifetime changes are fairly invasive and happened to break a bunch of things. Once all the rest is merged up, we can look into it again in more detail, isolated from the other bunch of changes.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream (was: Changing modes with fbset)
Subject: [Linux-fbdev-devel] fbdev upstream (was: Changing modes with fbset) Date: mer, dic 24, 2003 at 07:20:49 +1100
Quoted 3 lines · Benjamin Herrenschmidt
Since James vanished, I intend to take the most obvious bug fixes and driver updates from his tree into mine, test them, and then submit them one by one to Andrew Morton for 2.6.x inclusion.
I SECOND THAT! I am using your latest radeon driver with great happiness, and would be very happy to see it also merged into the official 2.6 release.
Merry xmas and all the rest.
Carlo
Signature · 10 lines
* Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - [email protected] che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
In reply to Benjamin HerrenschmidtQuoted 5 lines · Benjamin Herrenschmidt
Good catch. I merged that in my tree (I use a different version of the client notification mecanism though, I don't like much the version that James pushed).
Yeah. That has caused a lot of headaches for me as well. The fact that a vt row/col change triggers a fb resolution change which calls the vt resize routine again is just begging for an infinite loop. Just one calculation mistake of just one pixel in one of a dozen equations will trigger this loop. That's what the above bug does as well. The other major problem with it is that it only changes var.xres and var.yres and none of the other timings so the monitor won't sync anymore.
One item on my to do list is to make a separate fb_var_screeninfo for each vt so that we know what mode to switch back to when we switch vt's or come back from X or a fb graphical program.
Quoted 5 lines
Since James vanished, I intend to take the most obvious bug fixes and driver updates from his tree into mine, test them, and then submit them one by one to Andrew Morton for 2.6.x inclusion.
I'll keep posting any bugs I discover. Maybe you can post a message here whenever you've got a new version to test so that the other testers on the list and myself can try it out. I'm running fbcon on the radeon machine but I went back to VGA for the nvidia machines as the hardware cursor bug makes it unusable for any kind of text editing work. I'll switch back on those machines when that bug is squashed.
Quoted 7 lines
I do not intend, at least in a first step, to take the sysfs stuffs as the structure lifetime changes are fairly invasive and happened to break a bunch of things. Once all the rest is merged up, we can look into it again in more detail, isolated from the other bunch of changes.
Agreed. Let's get what we have rock solid before we try to break it again. :)
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 8 lines · John Zielinski
Quoted 5 lines · Benjamin Herrenschmidt
Good catch. I merged that in my tree (I use a different version of the client notification mecanism though, I don't like much the version that James pushed).
Quoted 7 lines
Yeah. That has caused a lot of headaches for me as well. The fact that a vt row/col change triggers a fb resolution change which calls the vt resize routine again is just begging for an infinite loop. Just one calculation mistake of just one pixel in one of a dozen equations will trigger this loop. That's what the above bug does as well. The other major problem with it is that it only changes var.xres and var.yres and none of the other timings so the monitor won't sync anymore.
Yes, that's fucked up from the very beginning. I've started working on a fix for that in my tree. stty doesn't work yet but fbset works again, but that require proper support from the fbdev's.
The idea is that fbcon will use FB_ACTIVATE_FIND instead of FB_ACTIVATE_TEST, which I defined to be "pick a mode suitable for the display based solely on xres/yres). In radeonfb, when you enable the DDC2/EDID support, I use the modedb I build from the monitor datas and I fallback to VESA modes (along with dealing with the fact that an LCD with a scaler can do pretty much anything).
It sort-of work (except for stty at this point), you can play with it, I pushed to my bk tree (using my earlier fb_client stuff, not the new gfx_client, which is the smae thing renamed in a way I don't like and I prefer individual functions in "ops" structure rather than one with a selector).
Of course, that means we'll have to update more drivers, and platforms with fixed display, like embedded etc... will need some way to deal with that properly in their drivers.
Quoted 3 lines
One item on my to do list is to make a separate
fb_var_screeninfofor each vt so that we know what mode to switch back to when we switch vt's or come back from X or a fb graphical program.
Heh, come back to what we had in 2.4 ? :)
That do make some sense though, provided those are hosted entirely by fbcon and aren't visible to fbdev's themselves.
Quoted 6 lines
Quoted 5 lines
Since James vanished, I intend to take the most obvious bug fixes and driver updates from his tree into mine, test them, and then submit them one by one to Andrew Morton for 2.6.x inclusion.
Quoted 6 lines
I'll keep posting any bugs I discover. Maybe you can post a message here whenever you've got a new version to test so that the other testers on the list and myself can try it out. I'm running fbcon on the radeon machine but I went back to VGA for the nvidia machines as the hardware cursor bug makes it unusable for any kind of text editing work. I'll switch back on those machines when that bug is squashed.
I don't know about that one. It would be interesting to redo some comparison between XFree CVS "nv" driver and rivafb. I don't have any nvidia HW at hand for now though. (I do have a GeForceIIMX AGP somewhere in a box, but I don't have an AGP slot machine that can grok it, so far I only have laptops, PCI-only old boxes and a G5 which wants 3.3V cards only afaik)
Quoted 10 lines
Quoted 7 lines
I do not intend, at least in a first step, to take the sysfs stuffs as the structure lifetime changes are fairly invasive and happened to break a bunch of things. Once all the rest is merged up, we can look into it again in more detail, isolated from the other bunch of changes.
Agreed. Let's get what we have rock solid before we try to break it again. :)
Something else I noticed: After playing with resize & console switches for a while, I had the kernel oops somewhere with this code path:
sys_write -> vfs_write -> pipe_write -> __wake_up -> __wake_up_common then jumping to random place.
Not sure at this point what's up, it happened when switching back to X gdm screen. I don't know if it's a latent 2.6.0 kernel bug, but it happened fairly quickly after playing with fbdev, at this point I wonder if there isn't some memory corruption going on. Part of the problem is that we may do printk's in the middle of vc_resize among other things, and I suppose that isn't totally safe.
Also, we just completely lack proper locking, we should at least take the console semaphore around all these operations, which we don't do and thus are racy as hell... the HW cursor and blanking timers are by definition racy too, we need to fix that some way.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 8 lines · Benjamin Herrenschmidt
The idea is that fbcon will use
FB_ACTIVATE_FINDinstead ofFB_ACTIVATE_TEST, which I defined to be "pick a mode suitable for the display based solely on xres/yres). In radeonfb, when you enable the DDC2/EDID support, I use the modedb I build from the monitor datas and I fallback to VESA modes (along with dealing with the fact that an LCD with a scaler can do pretty much anything).
That's my ultimate goal. There's a couple of things I'm working on to make that more robust. The DDC2/EDID works great, as long as my KVM is selecting that machine while it boots. There's also three seperate lists of video modes. Two in the kernel which are the regular and vesa lists and the modedb that fbset uses. What I want to eventually do is consolidate all that information along with custom timing modes and corrections to the DDC2 info based on monitor model and move that all to userspace. Then a script called on startup/shutdown/manually can take that database along with the current EDID and archive it into a intiramfs file fragment (you can concatenate a bunch together and the kernel will unpack them all). When the kernel boots it can access this information and pull in what it needs for the current card & monitor combo. Then it can delete the file from the initramfs to free memory or we can use my patch that makes initramfs swappable.
Quoted 7 lines
It sort-of work (except for stty at this point), you can play with it, I pushed to my bk tree (using my earlier
fb_clientstuff, not the newgfx_client, which is the smae thing renamed in a way I don't like and I prefer individual functions in "ops" structure rather than one with a selector).
I'll grab a copy and take a look.
Quoted 6 lines
Heh, come back to what we had in 2.4 ? :)
That do make some sense though, provided those are hosted entirely by fbcon and aren't visible to fbdev's themselves.
Yes. I'm putting this into fbcon. I agree that having the common stuff concentrated in one spot is better that having it scattered amongst all the drivers. Much cleaner and less maintenance problems.
Quoted 3 lines
I don't know about that one. It would be interesting to redo some comparison between XFree CVS "nv" driver and rivafb.
I though I read on the list somewhere that someone already fixed the nvidia hw cursor problem. I'll have to do a search for it.
Quoted 7 lines
Something else I noticed: After playing with resize & console switches for a while, I had the kernel oops somewhere with this code path:
sys_write->vfs_write->pipe_write->__wake_up->__wake_up_commonthen jumping to random place.
I noticed some strangeness like that as well depending how it took to do the video mode switch. The radeonfb driver does a yield call or something (can't remember at the top of my head) and if a timer kicks in it complains about "schedule while atomic". The resize loop problem also triggered various oops. A lot of stuff went away with that call to do_blank_screen(1) I put in as it shuts down the cursor timer and puts a few other things on hold. I think a mechanism that would replace that do_blank_screen(1) functionality between the vt code, fbcon and fbdev layers that can be initiated from any of the three is needed. That way if any one of the three layers needs to do something it can tell the other two to suspend operations until it's finished.
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 15 lines
That's my ultimate goal. There's a couple of things I'm working on to
make that more robust. The DDC2/EDID works great, as long as my KVM is
selecting that machine while it boots. There's also three seperate
lists of video modes. Two in the kernel which are the regular and vesa lists and the modedb that fbset uses. What I want to eventually do is consolidate all that information along with custom timing modes and corrections to the DDC2 info based on monitor model and move that all to
userspace. Then a script called on startup/shutdown/manually can take
that database along with the current EDID and archive it into a intiramfs file fragment (you can concatenate a bunch together and the kernel will unpack them all). When the kernel boots it can access this information and pull in what it needs for the current card & monitor combo. Then it can delete the file from the initramfs to free memory or we can use my patch that makes initramfs swappable.
Moving that to userland is a 2.7 goal. For 2.6, we should probably stay around what I'm doing in radeonfb. Also, we want the machine to have some sort of working console at boot. The VGA console exist only on some platforms like x86, for example, PPC needs a working mode at boot time.
Also, some drivers may have different monitor probing mecanism that DDC2/EDID. For example, old PowerMac drivers can probe the monitor type using an old Apple sepcific mecanism that leads to a modelist (macmodes) which is different. We currently don't deal with that very well though.
Quoted 3 lines
Yes. I'm putting this into fbcon. I agree that having the common stuff concentrated in one spot is better that having it scattered amongst all the drivers. Much cleaner and less maintenance problems.
The important point here is that fbdev must remain independant of fbcon, you can have fbdev without fbcon, all of the console cruft is not fbdev business.
Quoted 15 lines
Quoted 3 lines
I don't know about that one. It would be interesting to redo some comparison between XFree CVS "nv" driver and rivafb.
I though I read on the list somewhere that someone already fixed the nvidia hw cursor problem. I'll have to do a search for it.
Quoted 7 lines
Something else I noticed: After playing with resize & console switches for a while, I had the kernel oops somewhere with this code path:
sys_write->vfs_write->pipe_write->__wake_up->__wake_up_commonthen jumping to random place.
Quoted 11 lines
I noticed some strangeness like that as well depending how it took to do the video mode switch. The radeonfb driver does a yield call or something (can't remember at the top of my head) and if a timer kicks in it complains about "schedule while atomic". The resize loop problem also triggered various oops. A lot of stuff went away with that call to
do_blank_screen(1)I put in as it shuts down the cursor timer and puts a few other things on hold. I think a mechanism that would replace thatdo_blank_screen(1)functionality between the vt code, fbcon and fbdev layers that can be initiated from any of the three is needed. That way if any one of the three layers needs to do something it can tell the other two to suspend operations until it's finished.
We need a way to properly suspend cursor & blanking interrupts and synchronize them (I'd personally move blanking down to task time with schedule work and just take the console semaphore)
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 7 lines · Benjamin Herrenschmidt
Moving that to userland is a 2.7 goal. For 2.6, we should probably stay around what I'm doing in radeonfb. Also, we want the machine to have some sort of working console at boot. The VGA console exist only on some platforms like x86, for example, PPC needs a working mode at boot time.
That's why it's the ultimate goal. ;-) I'll still be working on it for this project I have but I'll keep it seperate until it's time to work on 2.7 stuff. I keep all my patches in small pieces so I can pick an chose which ones I want to work with at the moment. As for the working mode at boot time, that's not a problem. The initramfs archive is unpacked extrememly early in the boot process. The message for that apears way before the fbdev or fbcon messages come up. Many HDTV's don't sync to standard VGA signals so i need the proper mode up as soon as possible as well. The only problem is that a couple of models don't supply the correct DDC timings and the picture rolls. That's why I'd like to have the database available that early and to not require a kernel recompile to change it. But this is 2.7 stuff.
Quoted 7 lines
Also, some drivers may have different monitor probing mecanism that DDC2/EDID. For example, old PowerMac drivers can probe the monitor type using an old Apple sepcific mecanism that leads to a modelist (macmodes) which is different. We currently don't deal with that very well though.
Then a standard generic way to retrieve this information from the fbdev might be an idea. At the very least you should get the bare modelist but if the other info is available (manufacturer, model number, serial number, raw edid data) then that can be returned as well. Again this is 2.7 material.
Quoted 6 lines
The important point here is that fbdev must remain independant of fbcon, you can have fbdev without fbcon, all of the console cruft is not fbdev business.
That's why I'm putting a lot of my stuff into fbcon as it's console related. Is X the only other system to use fbdev other than fbcon?
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 6 lines
Then a standard generic way to retrieve this information from the fbdev
might be an idea. At the very least you should get the bare modelist
but if the other info is available (manufacturer, model number, serial
number, raw edid data) then that can be returned as well. Again this
is 2.7 material.
I think we need the driver to have a "detect displays" method ultimately, that builds either an identification string, or a modelist.
If we go to the ID string way, it could be something like
EDID,<EDID data in hex>
APPL,<Apple old style sense code>
FIXD,<fixed mode line>
(the above are random examples coming out of my mind right now)
Or we can have the driver build a modelist. Though if we are going to move things to userland, it makes sense to move the modelist building down there as well...
We also want to define some hotplug events for displays
Finally, we need to extend the fbdev API (via sysfs ?) to separate clearly the physical outputs (and detection of what they are connected to) from the actual CRTCs and some way to setup the mapping between outputs and CRTCs (1 CRTC routed to several outputs, 2 CRTCs on 2 different outputs, etc..)
I'm about to implement dual head in radeonfb, and the above is hell, I want to support mirroring for example, but then, you have only one /dev/fb entry and 2 different modes ... things like that... Getting the user API right isn't simple.
Quoted 2 lines
That's why I'm putting a lot of my stuff into fbcon as it's console
related. Is X the only other system to use fbdev other than fbcon?
No. There is an implementation of Mesa/DRI on top of fbdev (witout X), there is MacOnLinux virtual machine (running Linux, MacOS or MacOS X) that uses fbdev, there is directfb, at least...
One thing we discussed a while ago with Jon Smirl was to move the actual console engine out of the kernel. That's a possibility though may not be necessary as long as things are properly split. But I'd like to get rid of the accel ops in the kernel and shove all that in userland libs that can make use of CCE engines when available etc... and provide more APIs like surfaces overlay etc.. (useful for full screen set-top-box type applications).
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 10 lines · Benjamin Herrenschmidt
I think we need the driver to have a "detect displays" method ultimately, that builds either an identification string, or a modelist.
If we go to the ID string way, it could be something like
EDID,<EDID data in hex>
APPL,<Apple old style sense code>
FIXD,<fixed mode line>
Quoted 7 lines
(the above are random examples coming out of my mind right now)
Or we can have the driver build a modelist. Though if we are going to move things to userland, it makes sense to move the modelist building down there as well...
Sounds good. That way if fbcon is not being used then userland can worry about everything and if it is used it can parse that data and generate a good startup mode to use.
Quoted 8 lines
We also want to define some hotplug events for displays
Finally, we need to extend the fbdev API (via sysfs ?) to separate clearly the physical outputs (and detection of what they are connected to) from the actual CRTCs and some way to setup the mapping between outputs and CRTCs (1 CRTC routed to several outputs, 2 CRTCs on 2 different outputs, etc..)
Quoted 6 lines
I'm about to implement dual head in radeonfb, and the above is hell, I want to support mirroring for example, but then, you have only one
/dev/fbentry and 2 different modes ... things like that... Getting the user API right isn't simple.
I see what you mean. Looks like I need to do some research on sysfs and get more familiar with it. I'll help out any way I can.
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
In reply to Benjamin HerrenschmidtQuoted 4 lines · Benjamin Herrenschmidt
On Thu, 2003-12-25 at 07:40, John Zielinski wrote:
The idea is that fbcon will useFB_ACTIVATE_FINDinstead ofFB_ACTIVATE_TEST, which I defined to be "pick a mode suitable for the display based solely on xres/yres). In radeonfb, when you enable the
Can't you overload the `round up if it doesn't fit' rule to achieve this, instead of by adding FB_ACTIVATE_FIND?
I.e. the procedure becomes:
memset(var, 0, sizeof(*var);
var.xres = wanted_xres;
var.yres = wanted_yres;
var.bits_per_pixel = wanted_bpp;
ioctl(fd, FBIOPUT_VSCREENINFO, &var);Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
In reply to Benjamin HerrenschmidtQuoted 4 lines
Of course, that means we'll have to update more drivers, and platforms with fixed display, like embedded etc... will need some way to deal with that properly in their drivers.
Fixed screen size drivers should provide there own modedb.
Quoted 3 lines
I don't know about that one. It would be interesting to redo some comparison between XFree CVS "nv" driver and rivafb. I don't have any nvidia HW at hand for now though.
The changes have been alot. It would require me reworking the driver again.
Quoted 4 lines
Also, we just completely lack proper locking, we should at least take the console semaphore around all these operations, which we don't do and thus are racy as hell... the HW cursor and blanking timers are by definition racy too, we need to fix that some way.
The fbcon system has always lacked locking :-( Now it can be fixed. k
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 5 lines · James Simmons
Quoted 3 lines
Of course, that means we'll have to update more drivers, and platforms with fixed display, like embedded etc... will need some way to deal with that properly in their drivers.
Fixed screen size drivers should provide there own modedb.
Or just single mode... currently drivers don't export a modedb, they keep one internally and do the validation... though it would make sense to expose a modedb to userland, so we can have some nice GUI tools showing you the available modes :) It would make sense for MacOnLinux too which currently rely on the user to setup the list of modes available to MacOS.
Quoted 6 lines
Quoted 3 lines
I don't know about that one. It would be interesting to redo some comparison between XFree CVS "nv" driver and rivafb. I don't have any nvidia HW at hand for now though.
The changes have been alot. It would require me reworking the driver again.
Heh, been there, done that in 2.4... quite painful indeed. We can probably first get what we have merged upstream now, and think about it later...
Quoted 7 lines
Quoted 4 lines
Also, we just completely lack proper locking, we should at least take the console semaphore around all these operations, which we don't do and thus are racy as hell... the HW cursor and blanking timers are by definition racy too, we need to fix that some way.
The fbcon system has always lacked locking :-( Now it can be fixed. k
Signature · 9 lines
Benjamin Herrenschmidt <[email protected]> ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 4 lines · James Simmons
Quoted 3 lines
Of course, that means we'll have to update more drivers, and platforms with fixed display, like embedded etc... will need some way to deal with that properly in their drivers.
Quoted 8 lines
Quoted 1 line
Fixed screen size drivers should provide there own modedb.
Or just single mode... currently drivers don't export a modedb, they keep one internally and do the validation... though it would make sense to expose a modedb to userland, so we can have some nice GUI tools showing you the available modes :) It would make sense for MacOnLinux too which currently rely on the user to setup the list of modes available to MacOS.
And how to export it? Sysfs again, I guess...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 11 lines
Quoted 9 lines
Quoted 2 lines
Fixed screen size drivers should provide there own modedb.
Or just single mode... currently drivers don't export a modedb, they keep one internally and do the validation... though it would make sense to expose a modedb to userland, so we can have some nice GUI tools showing you the available modes :) It would make sense for MacOnLinux too which currently rely on the user to setup the list of modes available to MacOS.
And how to export it? Sysfs again, I guess...
Yeap. I have been looking at sysfs. Very nice. I have lots of ideas but that will be for later.
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
Re: fbdev upstream
In reply to John ZielinskiQuoted 5 lines
on the list and myself can try it out. I'm running fbcon on the radeon machine but I went back to VGA for the nvidia machines as the hardware cursor bug makes it unusable for any kind of text editing work. I'll switch back on those machines when that bug is squashed.
Endian issue for the nvidia card. I have been tracking that bug down. I should have a fix very soon.
Quoted 2 lines
Agreed. Let's get what we have rock solid before we try to break it again. :)
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Re: fbdev upstream
Quoted 3 lines · James Simmons
Endian issue for the nvidia card. I have been tracking that bug down. I should have a fix very soon.
Cool! Can't wait to switch those machines to fbcon. Regular text mode drives me nuts as the y res is too low and the gaps between the scan lines give me eye strain.
John
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
Re: fbdev upstream
I will work on teh riva driver thsi weekend.
Quoted 6 lines · John Zielinski
Quoted 4 lines · James Simmons
Endian issue for the nvidia card. I have been tracking that bug down. I should have a fix very soon.
Quoted 8 lines
Cool! Can't wait to switch those machines to fbcon. Regular text mode drives me nuts as the y res is too low and the gaps between the scan lines give me eye strain.
John
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
James Simmons
AppliedApplied. Thanks for finding that.
Quoted 28 lines · John Zielinski
Found it. It's a bug in
fbcon.cwhere the rows and cols were mixed up sofbcon_resizetries to set the mode again with xres and yres reversed. Didn't happen during boot asfbcon_state_manageris registered after the console is taken over.diff -urNX dontdiff
linux.old/drivers/video/console/fbcon.clinux/drivers/video/console/fbcon.cdrivers/video/console/fbcon.c +2
-2@@ -2261,8 +2261,8 @@// Switch resolution size int rows, cols; - rows = info->var.xres / vc->vc_font.height; - cols = info->var.yres / vc->vc_font.width; + rows = info->var.yres / vc->vc_font.height; + cols = info->var.xres / vc->vc_font.width;fbcon_resize (vc, cols, rows); info->state |= flag; }John
Quoted 10 lines
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 2 lines · James Simmons
Applied. Thanks for finding that.
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
-solca
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 4 lines · Otto Solares
Quoted 2 lines · James Simmons
Applied. Thanks for finding that.
Quoted 9 lines
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
Right, we need that and some way to know which heads are "coupled" for dual head drivers. One of the reasons I haven't done dual head support in radeonfb yet is that to get it working properly with X, I need to update X too, and add a way for X to know which /dev/fb's are actually "together" as 2 heads of the same card.
Then, we probably want some way to also enable mirroring instead of dual head...
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 15 lines · Benjamin Herrenschmidt
Quoted 4 lines · Otto Solares
Quoted 2 lines · James Simmons
Applied. Thanks for finding that.
Quoted 9 lines
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
Quoted 5 lines
Right, we need that and some way to know which heads are "coupled" for dual head drivers. One of the reasons I haven't done dual head support in radeonfb yet is that to get it working properly with X, I need to update X too, and add a way for X to know which /dev/fb's are actually "together" as 2 heads of the same card.
Finding "coupled" cards could be as easy as checking if the fbdev api returns the same busid for both fbdev's.
-solca
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 4 lines
Finding "coupled" cards could be as easy as checking if the fbdev api returns the same busid for both fbdev's.
That would work as long as you don't have a single PCI chip providing 2 separate independant sets of heads but I agree this is very unlikely :)
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 7 lines · Benjamin Herrenschmidt
Quoted 4 lines
Finding "coupled" cards could be as easy as checking if the fbdev api returns the same busid for both fbdev's.
That would work as long as you don't have a single PCI chip providing 2 separate independant sets of heads but I agree this is very unlikely :)
I have not seen that cards but maybe is just a difference in the function number from the busid.
Ben, you that know the internals of fbdev's, it would be difficult to implement the busid stuff? Maybe that info is already known by the drivers somewhere... It could even work for sparcs with sbus or others archs with differents buses, as the busid nomenclature is very standarized i think.
-solca
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 6 lines
Ben, you that know the internals of fbdev's, it would be difficult to implement the busid stuff? Maybe that info is already known by the drivers somewhere... It could even work for sparcs with sbus or others archs with differents buses, as the busid nomenclature is very standarized i think.
Fairly easy, though it would be even better to do it based on the sysfs stuff rather than an ioctl.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 9 lines · Benjamin Herrenschmidt
Quoted 6 lines
Ben, you that know the internals of fbdev's, it would be difficult to implement the busid stuff? Maybe that info is already known by the drivers somewhere... It could even work for sparcs with sbus or others archs with differents buses, as the busid nomenclature is very standarized i think.
Fairly easy, though it would be even better to do it based on the sysfs stuff rather than an ioctl.
Agree. Problem is that sysfs stuff is very invasive i think and it will be hard to push even on development trees like -mm ones. An ioctl could be something simple as passing a pointer to a buffer of fixed length, the best imho would be extend fb_fix_screeninfo struct to accomodate a 'char busid[16];' but that could break binary compatibility. If 2.6 break from 2.4 we could put it there as anyway apps need to recompile. Shame that there are not sufficient 'reserved' bits.
-solca
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
A message that is not in the archive (sent off-list or not yet received): 1073354986.761.208.camel@gaston
Quoted 11 lines · Benjamin Herrenschmidt
Quoted 9 lines
Agree. Problem is that sysfs stuff is very invasive i think and it will be hard to push even on development trees like -mm ones. An ioctl could be something simple as passing a pointer to a buffer of fixed length, the best imho would be extend
fb_fix_screeninfostruct to accomodate a 'char busid[16];' but that could break binary compatibility. If 2.6 break from 2.4 we could put it there as anyway apps need to recompile. Shame that there are not sufficient 'reserved' bits.We can just add it to
fb_infoand return if from an ioctl...
Great! hopefully James will agree!.. :)
-solca
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 12 lines · Benjamin Herrenschmidt
Quoted 10 lines · Otto Solares
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
Quoted 8 lines
Right, we need that and some way to know which heads are "coupled" for dual head drivers. One of the reasons I haven't done dual head support in radeonfb yet is that to get it working properly with X, I need to update X too, and add a way for X to know which /dev/fb's are actually "together" as 2 heads of the same card.
Then, we probably want some way to also enable mirroring instead of dual head...
Crazy idea: What would break if it defaulted to mirroring? :) You could achieve true multihead via panning or something...
Signature · 10 lines
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 6 lines · On Tue, 6 Jan 2004, Michel [ISO-8859-1] Dänzer wrote:
Quoted 2 lines · Benjamin Herrenschmidt
Then, we probably want some way to also enable mirroring instead of dual head...
Crazy idea: What would break if it defaulted to mirroring? :) You could achieve true multihead via panning or something...
Not that crazy!
It would revert the current con2fbmap approach: instead of mapping virtual consoles to frame buffer devices, it would allow to map frame buffer devices to a virtual console or to another frame buffer device...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
Quoted 4 lines · Otto Solares
Quoted 2 lines · James Simmons
Applied. Thanks for finding that.
Quoted 9 lines
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
The patches are getting pushed. With sysfs the info is there :-)
Quoted 4 lines
-solca
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
Quoted 16 lines · James Simmons
Quoted 4 lines · Otto Solares
Quoted 2 lines · James Simmons
Applied. Thanks for finding that.
Quoted 9 lines
Hi James! now that you are back again, i would like to suggest a modification to fbdev core, i am having problems guessing which card is attached to a fb device. I need this info to solve the 'more than 1 card' situation. This could be easily fixed if the fbdev api provides the busid of the card, like "pci:0000:01:0.0". That would solve a lot of things in the HAL detection routines. Maybe that could be exported via sysfs but i have been waiting for sysfs for a while and don't see it coming to a reality. Maybe an ioctl is enough.
Quoted 1 line
The patches are getting pushed. With sysfs the info is there :-)
Great!
-solca
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
Quoted 1 line · James Simmons
Applied. Thanks for finding that.
Still... I don't get anything useful with just calling fbcon_resize, though I do get something right if I actually call vc_resize. There is a possible problem with "looping" between the callback and resize that I currently fixed with a global flag. Note that the whole stty thing only works properly if the fbdev do some mode validation (see my note about FB_ACTIVATE_FIND).
I'm posting a set of patches againts current 2.6.1-rc separately
Ben.
Signature · 9 lines
Benjamin Herrenschmidt <[email protected]> ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 9 lines
Still... I don't get anything useful with just calling
fbcon_resize, though I do get something right if I actually callvc_resize. There is a possible problem with "looping" between the callback and resize that I currently fixed with a global flag. Note that the whole stty thing only works properly if the fbdev do some mode validation (see my note aboutFB_ACTIVATE_FIND).I'm posting a set of patches againts current 2.6.1-rc separately
Your right. We need to call vc_resize.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Quoted 3 lines · James Simmons
Applied. Thanks for finding that.
No problem. BTW, do you have a CVS repository? I'm just grabbing that fbdev.diff.gz at the location that was posted in this list a while back.
John
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
No CVS but we do have a BK tree. I send out patches for those you don't like Bitkeep.
Quoted 13 lines · John Zielinski
Quoted 3 lines · James Simmons
Applied. Thanks for finding that.
No problem. BTW, do you have a CVS repository? I'm just grabbing that fbdev.diff.gz at the location that was posted in this list a while back.
John
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html