Changing modes with fbset

Changing modes with fbset

[John Zielinski]

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

Re: Changing modes with fbset

[John Zielinski]

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.


diff -urNX dontdiff linux.old/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux.old/drivers/video/console/fbcon.c	2003-12-13 19:32:14.000000000 -0500
+++ linux/drivers/video/console/fbcon.c	2003-12-13 19:34:48.000000000 -0500
@@ -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)

[Benjamin Herrenschmidt]

On Sun, 2003-12-14 at 12:14, John Zielinski wrote:
> 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.

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)

[Carlo E. Prelz]

	Subject: [Linux-fbdev-devel] fbdev upstream (was: Changing modes with fbset)
	Date: mer, dic 24, 2003 at 07:20:49 +1100

Quoting Benjamin Herrenschmidt (benh@kernel.crashing.org):

> 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

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             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

[John Zielinski]

Benjamin Herrenschmidt wrote:

>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.

>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.

>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

[Benjamin Herrenschmidt]

On Thu, 2003-12-25 at 07:40, John Zielinski wrote:
> Benjamin Herrenschmidt wrote:
> 
> >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.

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.

> 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.

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.

> >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.

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)
 
> >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

[John Zielinski]

Benjamin Herrenschmidt wrote:

>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).
>  
>

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.

>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).
>  
>

I'll grab a copy and take a look.

>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.

>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.

>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.
>  
>

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

[Benjamin Herrenschmidt]

> 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.
 
> 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.

> >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.
> 
> >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.
> >  
> >
> 
> 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.

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

[John Zielinski]

Benjamin Herrenschmidt wrote:

>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.

>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.

>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

[Benjamin Herrenschmidt]

> 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.

> 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

[John Zielinski]

Benjamin Herrenschmidt wrote:

>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...
>  
>

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.

>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.
>  
>

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

[Geert Uytterhoeven]

On Thu, 25 Dec 2003, Benjamin Herrenschmidt wrote:
> On Thu, 2003-12-25 at 07:40, John Zielinski wrote:
> 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

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 -- geert@linux-m68k.org

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: Changing modes with fbset

[James Simmons]

Applied. Thanks for finding that.

On Sat, 13 Dec 2003, John Zielinski wrote:

> 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.
> 
> 
> diff -urNX dontdiff linux.old/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
> --- linux.old/drivers/video/console/fbcon.c	2003-12-13 19:32:14.000000000 -0500
> +++ linux/drivers/video/console/fbcon.c	2003-12-13 19:34:48.000000000 -0500
> @@ -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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> 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

Re: Changing modes with fbset

[Otto Solares]

On Tue, Jan 06, 2004 at 12:06:04AM +0000, James Simmons wrote:
> 
> 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

Re: Changing modes with fbset

[Benjamin Herrenschmidt]

On Tue, 2004-01-06 at 11:06, James Simmons wrote:
> 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.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
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: Changing modes with fbset

[Benjamin Herrenschmidt]

On Tue, 2004-01-06 at 11:28, Otto Solares wrote:
> On Tue, Jan 06, 2004 at 12:06:04AM +0000, James Simmons wrote:
> > 
> > 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.

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

Re: Changing modes with fbset

[James Simmons]

> 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

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

Re: fbdev upstream

[James Simmons]

> 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.
 
> 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

[James Simmons]

> 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. 

> 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.

> 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

[Benjamin Herrenschmidt]

On Tue, 2004-01-06 at 11:51, James Simmons wrote:
> > 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.

> > 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...

> > 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
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
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: Changing modes with fbset

[Otto Solares]

On Tue, Jan 06, 2004 at 11:35:49AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2004-01-06 at 11:28, Otto Solares wrote:
> > On Tue, Jan 06, 2004 at 12:06:04AM +0000, James Simmons wrote:
> > > 
> > > 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.
> 
> 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

Re: Changing modes with fbset

[Benjamin Herrenschmidt]

> 
> 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

Re: Changing modes with fbset

[Otto Solares]

On Tue, Jan 06, 2004 at 12:09:44PM +1100, Benjamin Herrenschmidt wrote:
> 
> > 
> > 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

Re: Changing modes with fbset

[Benjamin Herrenschmidt]

> 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

Re: Changing modes with fbset

[Otto Solares]

On Tue, Jan 06, 2004 at 12:44:39PM +1100, Benjamin Herrenschmidt wrote:
> 
> > 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

Re: Changing modes with fbset

[Otto Solares]

On Tue, Jan 06, 2004 at 01:09:47PM +1100, Benjamin Herrenschmidt wrote:
> 
> > 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.
> 
> We can just add it to fb_info and 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

Re: fbdev upstream

[Geert Uytterhoeven]

On Tue, 6 Jan 2004, Benjamin Herrenschmidt wrote:
> On Tue, 2004-01-06 at 11:51, James Simmons wrote:
> > > 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.

And how to export it? Sysfs again, I guess...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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: Changing modes with fbset

[Michel Dänzer]

On Tue, 2004-01-06 at 01:35, Benjamin Herrenschmidt wrote:
> On Tue, 2004-01-06 at 11:28, Otto Solares wrote:
> > 
> > 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...

Crazy idea: What would break if it defaulted to mirroring? :) You could
achieve true multihead via panning or something...


-- 
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

Re: Changing modes with fbset

[Geert Uytterhoeven]

On Tue, 6 Jan 2004, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2004-01-06 at 01:35, Benjamin Herrenschmidt wrote:
> > 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 -- geert@linux-m68k.org

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\x1278&alloc_id371&op=click

Re: Changing modes with fbset

[John Zielinski]

James Simmons wrote:

>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

Re: fbdev upstream

[John Zielinski]

James Simmons wrote:

>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

[James Simmons]

I will work on teh riva driver thsi weekend.



On Wed, 7 Jan 2004, John Zielinski wrote:

> James Simmons wrote:
> 
> >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: Changing modes with fbset

[James Simmons]

No CVS but we do have a BK tree. I send out patches for those you don't 
like Bitkeep.



On Wed, 7 Jan 2004, John Zielinski wrote:

> James Simmons wrote:
> 
> >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

Re: Changing modes with fbset

[James Simmons]

On Mon, 5 Jan 2004, Otto Solares wrote:

> On Tue, Jan 06, 2004 at 12:06:04AM +0000, James Simmons wrote:
> > 
> > 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.

The patches are getting pushed. With sysfs the info is there :-)



> 
> -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

Re: Changing modes with fbset

[Otto Solares]

On Fri, Jan 09, 2004 at 12:03:16AM +0000, James Simmons wrote:
> On Mon, 5 Jan 2004, Otto Solares wrote:
> 
> > On Tue, Jan 06, 2004 at 12:06:04AM +0000, James Simmons wrote:
> > > 
> > > 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.
> 
> 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

Re: fbdev upstream

[James Simmons]

> > > 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