Re: [PATCH] sysfs support for fbdev

[Jon Smirl <jonsmirl@gmail.com>]

On Thu, 3 Mar 2005 00:12:22 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
> 
> > Have you considered moving all of the monitor support out into a
> > hotplug helper app? This will even work at boot time since early user
> > space is there when fbdev initializes. The helper app would be on
> > initrd just like the boot disk drivers.
> 
> Consider the following case. I have high end server with fbcon running as
> the console. One VC is at a different resolution than another. Now say the
> system is under really heavy load. When I VC switch I would have to wait
> until userland sets up the proper mode for me to VC switch. Consider also
> if userland apps start getting killed. I'm limited to only VCs of the same
> resolution if that helper app dies :-(

It is a helper app, not a daemon, it does not stay running. It also
only runs when the monitor is changed - not mode change, monitor
changed. On monitor change (loading fbdev counts as a monitor change)
the helper is called. The helper reads the DDC, parses it, merges in
any updates from /etc/fb.modes (or builds a modelist from fb.modes if
no DDC), and then sets this list of legal modes into the driver. After
the list is set a hal/dbus event is generated. Doing this is a root
only operation.

It can also happen in early user space when the kernel is first
booting. Early user space starts before fbcon currently starts. The
helper app would be loaded on to initrd or initramfs.

To change a mode, pick one of the mode names from the mode_list and
cat it to /sys/graphics/fbX/mode. This will cause the mode to be set
and a hal/dbus event to be generated. If you are just running console
the mode change event goes into fbcon. Any user can now safely set a
mode.

Changing modes does not require a user space helper, only changing
monitors (flipping a KVM switch for example).

I have working code for generating the interrupt on monitor change but
it isn't ready yet to send out.

This is the complete event sequence....

modprobe card driver
card driver checks if post needed, if so uses a new version of
request_firmware() to post
sys/graphics/fbX is added for each head
udev builds /dev/fbX for each head
1) driver locates monitors
creates sys/graphics/fbX/monitor(edid)
creating this causes a hotplug event
root priv hotplug event parses edid merges etc/mode file
sets legal modes back into sys/graphics/fbX(mode-list)
altering the modelist causes an event hal/dbus can see
user space mesa/X reads the mode-list, strings like 1024x768-60
set the one you want back into sys/graphics/fbX(mode)
this causes another hal/dbus event

If the card supports an interrupt on monitor change, flipping a KVM
switch will restart the process at #1.

Mode lists are generated at root priv.
Pam assigns ownership of mode variable to user
This allows a non-root user to safely set the mode

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click