> What this is saying is that very early in the boot process the graphics driver
> will be initialized. At this point it will generate a hotplug event. This event
> will be handled by an app and lib that live in initramfs. This is not saying
> that mode-setting will be delayed until normal user space starts. The initial
> hotplug event occurs very early in the boot process, almost as early as the
> current device driver based code runs.
Right now alot of application including commerical depend on setting the
video mode via /dev/fb. I like to have /sys do that in the future. If that
goes away it will break alot of software. Hurt alot of companies.
Now consider these apps in the future and how with the above will work.
app -> /dev/fb to change mode
-> context switch to kernel
-> send hot plug event
-> userland app grabs event
-> loads library to execute the code if it hasn't done so already
-> set mode in userland library
-> via a ioctl creates a event packet to send back to kernel to let
them know it worked. Also we need to send back detail data on the
new mode for the app. We might of not got the exact mode we wanted
so we send back the closes thing we wanted.
-> context switch to kernel
-> store new data kernel side.
-> call library to grab new resolution data for a app.
Now you could say we could remove the fbdev interface completely and move
to the library. But then you have the below case.
Now consider the case of a VC switch where two VC's are at different
resolutions. Say one is at 80x30 and the other is 128x48
You press Alt-Fx -> VT code call console_callback
-> send a hotplug event to userland
-> a userland app gets the event
-> loads the userland library
-> executes the code to set the video mode
-> send back a ok from userland. Again we need to send
a packet back to kernel to let them know if it was
successful. Also we need to let them know the exact
details of the mode we actually got.
-> context switch to kernel
-> write new data to struct vc_data.
This is a really expensive solution.
I understand you point of the mode switching code being huge. The embedded
guys require really lean kernels. I have no problem making the mode switching
code modular. I just want to avoid the above overhead.
> This is very similar to the way udev works. Udev is a user space replacement for
> devfs. Instead of having a /dev with 40,000 devices in it, udev builds one on
> the fly at each boot with exactly your devices in it. Now that I have used udev
> instead of devfs I have to agree that it is a much better solution. In fact the
> udev app will run before the mode-setting app since it's the udev app that
> creates the devices in /dev now by detecting additions to sysfs. udev FAQ:
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
> We all know Linux is non-functional without a /dev directory, and now /dev is
> being build in user space.
I also like udev much more than devfs. The difference is that userland
doesn't modify device nodes. You create them and you remove them. Very
basic. Fbdev is a bit more complex than that. You can see that in the
above arguments.
> Andrew, akpm, has also explained to me that even the current fbdev is not
> really active at boot. Instead those initial printk's are queued until
> the fbdev driver initialized and prints them.
That is true and I consider it a bug. The true is that the fbdev layer
could be started right away for most of the drivers. Most fbdev devices
are embedded devices which don't need a bus initialized first. Even on
intel you could have the vga16 driver started at the exact same time as
vgacon. The limitation is only for devices like pci. Personally I like to
see fbcon start at the same time as vgacon and the rest and if the
graphics card is pci then when it initializes then start drawing the data.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
