radeonfb work (WAS: Merge of Luca and Ben's sysfs work for Radeon)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2003-09-25 at 08:05, Jon Smirl wrote:
> Here is a sample of what sysfs looks like with the new radeon driver. I have an
> Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
> that the EDID block is available.
> 
> I was thinking about adding these attributes to the fb device: geometry,
> timings, interlaced, hsync, vsync. and then writing a new fbset command.

Note that there are still missing things in this driver. I'm in the
process of reworking more of it, the goal is to make it much closer
to XFree current driver so we have a chance to better deal with
newer cards & some nasty corner cases, and so it becomes easier in
the future to re-integrate XFree originated changes.

James: I'm in bad need of notifying fbcon of resolution changes. For
example, I want to add a switch for mirror on/off that could easily
be tied to the common "mirror" key on laptops (for machines that don't
do that via BIOS horros of course). However, since a bunch of panels
now have resolutions unsuitable for the external CRT, I will probably
change the panel resolution based on the external monitor (using the
scaler) when this key is pressed. For example, titanium powerbooks
with 1152x768 resolutions would switch to 1024x768 when mirroring
to a CRT...
 
I'm not too sure yet in fact about how to deal with this whole API. The
current set_var doesn't seem to bad if we can add a few flags to it,
like indicating a mirrored mode... The best way may be to add such a flag
to the modes in a mode list indicating "mirrorable" modes (fitting both
displays). The user would see that flag when retreiving the mode list
via /sys or whatever and would pass "mirror" flag to set_var when picking
one of these 'mirrored' modes...

I also want to let the user go up in resolutions when disabling the internal
LCD etc... MacOS lets you diable the LCD if have the laptop lid closed when
waking the machine up from sleep (with an external kbd), though I'm not sure
what is the best way to deal with that with radeonfb.

All that means I'll have actions on ioctl and/or sysfs that will trigger
mode changes and we want fbcon to adapt.

However, we also need a way to notify userland client apps (and maybe a
way for those to "lock" changes, but I don't like that much). That must be
done, I think, in a way similar to console switch: First notify of a
pending event, then wait for the userland app to acknowledge the change.
Not doing so would cause a lot of problems with userland apps tapping the
engine.

Any ideas welcome, I'm still trying to figure out what would be the best
API for those things. We can think about it now, just defining new flags,
ioctls and/or /sys entries won't harm compatibility or stability regarding
current 2.6 "code freeze". Since most of these "features" would then be
implemented on a per-driver basis, it will be up to the various driver
maintainers to deal with avoiding regressions (rather easy with radeonfb
seeing how bad the older versions of this driver worked on most recent hw)

Ben.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf