Re: Current discussion about the future of free software graphics
On Wed, 2004-05-12 at 05:30, Jon Smirl wrote: > If everyone will please read Benh's original post describing this... Ben and I > had been emailing on this topic before he wrote this. > > --- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > I agree with the idea of moving the EDID decoding & mode selection to > > userland. In this regard, though, I beleive we should aim toward some > > simple library that sits with the kernel, eventually distributed with > > the kernel tree, to live in initramfs optionally since it may be > > required to even get a console at boot (which is fine, initramfs is > > available early). The video cards themselves have PCI drivers that can > > "trigger" detection by the library via hotplug, the library could manage > > things like persistent configuration, either separate desktops or > > geometry of a complex desktop, etc... and eventually notification of > > userland clients of mode changes. > > > > One reason for that is lots of monitors lie about their capabilities in > > their EDID block, so we want "override" files. > > > > The kernel driver in this case doesn't need to be that much different > > than the current fbdev's though, except that we want to move the HW > > access for graphics commands to the kernel too, which basically turns > > into merging the DRI driver and the fbdev. There is no need, I think, to > > re-invent the wheel from scratch here, it would be a lot more realistic > > to build on top of those existing pieces. > > 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. Sure, because Ben doesn't talk about moving mode-setting to userland at all AFAICT. :) > I've already built a very messy prototype by moving the existing fbdev > code to user space and it works just fine. Maybe if others could play with this prototype... -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Around 9 o'clock on May 12, Keith Whitwell wrote: > My one worry about the discussion is that because of confusion over where the > X developers are hanging out nowadays, they are missing out on having their > say on this - and they probably care deeply about modesetting. Egbert and I are here; I'm not sure who else wants to be involved at this point. I know I'm hoping that a great deal of the mode setting logic disappears from my piece of the system soon. -keith pgp0.pgp Description: PGP signature
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
cvs -d:[EMAIL PROTECTED]:/cvs/mesa co drm it is in the video reset directory. you will need to modify it a little for command line use since it is meant to be called from a hotplug event --- Richard Smith <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > > licenses). I've already built a very messy prototype by moving the existing > > fbdev code to user space and it works just fine. I also called another > little > > app which executed the VBIOS and reset secondary cards at boot via hotplug. > > Is that app available somewhere? I'm trying to get an ATI Rage Mobility > M1 chip up under LinuxBIOS and such and app would be useful for me. > > > > > --- > 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 = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> > That app must be pretty big if it runs on non intel platforms. You nedd to > > translate the x86 BIOS code to native assembly before you run it. > > Or interprete it. Only if we could use Java for the video BIOS. --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> 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.
And for an embedded device with a fixed LCD screen you can easily make the mode
setting code __init, and disallow mode changes after boot up. One device
driver, just one more kernel config option. Some code has to do the mode
setting anyway, so better keep it in one place.
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 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
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> Anyway. I've got a lot of respect for the people involved in the discussion, > even when they hold quite conflicting views, so I'm hopeful that some sort of > direction can be reached for moving forward. I apologize for getting over heated. I'm very protective of the companies that work in the embedded space. I don't want to see them go away. They are vitial to linux. I know this might get some people upset but IMNSHO the linux community is going after the wrong goal. Everyone keeps thinking desktop PC. We don't have the resources to win that war and second the PC is NOT the future. I work for a asian company and when you go to the asian rim you see that the latest technology is in the embedded space. Look all around you. Embedded devices are everywhere. In stoplights, cars, supermarkets, tv, dvd players. Next time you use your printer look at the little display. Guess what? That printer is most likely a linux box and that little display is a framebuffer devices. How do I know? Because I wrote that code for the last company I worked at. For the embedded space we do have the resources to win that area of the market if we provide the tools they need to succeed. What do most people use there laptops for. Mostly playing movies. I also see embedded devices coming to this market soon that do the same thing for alot less money. Even the 3D graphics market is moving away from the PC to game consoles. > My one worry about the discussion is that because of confusion over where the > X developers are hanging out nowadays, they are missing out on having their > say on this - and they probably care deeply about modesetting. Though, given > the mad flamewar it's turned into, maybe smaller is better... Sorry about the flamewar. --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> > > That app must be pretty big if it runs on non intel platforms. You nedd to
> > > translate the x86 BIOS code to native assembly before you run it.
> >
> > Or interprete it.
>
> Only if we could use Java for the video BIOS.
Java? em86 (written by Gabriel Paubert) has been working fine on my PPC box
since 1998.
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 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Wed, 12 May 2004, James Simmons wrote:
> That app must be pretty big if it runs on non intel platforms. You nedd to
> translate the x86 BIOS code to native assembly before you run it.
Or interprete it.
> On Wed, 12 May 2004, Richard Smith wrote:
> > Jon Smirl wrote:
> > > licenses). I've already built a very messy prototype by moving the existing
> > > fbdev code to user space and it works just fine. I also called another little
> > > app which executed the VBIOS and reset secondary cards at boot via hotplug.
> >
> > Is that app available somewhere? I'm trying to get an ATI Rage Mobility
> > M1 chip up under LinuxBIOS and such and app would be useful for me.
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 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
> > > > That app must be pretty big if it runs on non intel platforms. You nedd to > > > > translate the x86 BIOS code to native assembly before you run it. > > > > > > Or interprete it. > > > > Only if we could use Java for the video BIOS. > > Java? em86 (written by Gabriel Paubert) has been working fine on my PPC box > since 1998. It was a joke. --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
James Simmons wrote: That app must be pretty big if it runs on non intel platforms. You nedd to translate the x86 BIOS code to native assembly before you run it. Or you emulate thier functionality.. but perhaps thats what you are saying. Thats what X does. LinuxBIOS has pulled the x86emu out into a standalone userspace app that we use to try and get video cards up across a serial console. Currently that app is 400k (dynamic linked) The plan though is to include that emulation ability into LinuxBIOS and 400k is way to large. The authors feel though that it can be done. I think the core pieces aren't really that big. It dosen't seem to work with my ATI bios though which is why I was interested in another implementation. Word is that the current LinuxBIOS implementation has issues with int10 replacement and then calling back into itself. Jon Smirl wrote: licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. Is that app available somewhere? I'm trying to get an ATI Rage Mobility M1 chip up under LinuxBIOS and such and app would be useful for me. --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
That app must be pretty big if it runs on non intel platforms. You nedd to translate the x86 BIOS code to native assembly before you run it. On Wed, 12 May 2004, Richard Smith wrote: > Jon Smirl wrote: > > > licenses). I've already built a very messy prototype by moving the existing > > fbdev code to user space and it works just fine. I also called another little > > app which executed the VBIOS and reset secondary cards at boot via hotplug. > > Is that app available somewhere? I'm trying to get an ATI Rage Mobility > M1 chip up under LinuxBIOS and such and app would be useful for me. > > > > > --- > 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 > ___ > Linux-fbdev-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Tue, May 11, 2004 at 08:30:45PM -0700, Jon Smirl wrote: [...] > So moving mode setting to user space is not the end of the world. Everything > will still work. This is more like a monolithic vs microkernel type of decision. Which is why Linux is a monolithic kernel, it's by design. The net is plenty of linus' threads about this. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
Re: Current discussion about the future of free software graphics
On Maw, 2004-05-11 at 20:55, James Simmons wrote: > Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't > never win this fight. There is MONEY involved here. This is a sure way > to make sure Tungstengraphics has a income coming in. They want a monoply > on the linux graphics arena then fine they can have it. Current DRI is certainly a PITA unless you know it well but the kernel side is quite trivial underneath the macrotrastrophe and preprocessor abuse. Its mappable buffers, queue, interrupt handler, X<->kernel auth mapping, and thats it Also I'd note several folks are doing DRI nowday without Tungsten - VIA did the Savage and VIA drivers, sis6326 is a WIP but its also not tungsten stuff. --- 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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Jon Smirl wrote: licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. Is that app available somewhere? I'm trying to get an ATI Rage Mobility M1 chip up under LinuxBIOS and such and app would be useful for me. --- 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
Re: Current discussion about the future of free software graphics
sottek writes: > Can we wrap this up the discussion and try to get to a consensus on > design requirements? I think most of the opinions are starting to > solidify enough to start hashing out the requirements and actual > design. > > Also, we probably want to drop the communication down to just one > list? I think dri-devel seems to have the widest group of subscribers. Well, I would think there are a lot more people who are interested in this subject than are subscribed on dri-devel. dri-devel really has a different scope. > 4: Design must insure that user applications may not set the hardware > into an unstable state that could lead to lockup or damage display > devices. The 'driver' must do mode validation using data supplied by either the display itself or the application (you need the second as some display devices may not support sending this data or the data sent is bogus). Broken video modes usually result from: 1. broken drivers 2. bogus user level configuration/override Egbert. --- 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
Re: Current discussion about the future of free software graphics
On Tue, 2004-05-11 at 20:09, sottek wrote: > Can we wrap this up the discussion and try to get to a consensus on > design requirements? I think most of the opinions are starting to > solidify enough to start hashing out the requirements and actual > design. I agree, and I like your initial list of requirements. > Also, we probably want to drop the communication down to just one > list? I think dri-devel seems to have the widest group of subscribers. I agree with Geert, that probably doesn't cut it. Maybe start a new list and widely send out invitations to discuss the design there? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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
Re: [Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
Ian Romanick wrote:
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I
couldn't never win this fight. There is MONEY involved here. This is a
sure way
to make sure Tungstengraphics has a income coming in. They want a
monoply on the linux graphics arena then fine they can have it.
Are you completely without a clue? Nobody from TG is even participating
in this discussion (except a couple messages from Jens a week or so
ago). Why would you even say such a thing?
I do feel remiss that I'm not engaged more fully in this, but really much of
the ground covered is way outside the areas in which I feel qualified to
comment, or perhaps it's just that I don't have an opinion either way about
mode-setting, etc, based on long years of just having the X server take care
of it for me...
Anyway. I've got a lot of respect for the people involved in the discussion,
even when they hold quite conflicting views, so I'm hopeful that some sort of
direction can be reached for moving forward.
My one worry about the discussion is that because of confusion over where the
X developers are hanging out nowadays, they are missing out on having their
say on this - and they probably care deeply about modesetting. Though, given
the mad flamewar it's turned into, maybe smaller is better...
Keith
---
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
Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
If everyone will please read Benh's original post describing this... Ben and I had been emailing on this topic before he wrote this. --- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > I agree with the idea of moving the EDID decoding & mode selection to > userland. In this regard, though, I beleive we should aim toward some > simple library that sits with the kernel, eventually distributed with > the kernel tree, to live in initramfs optionally since it may be > required to even get a console at boot (which is fine, initramfs is > available early). The video cards themselves have PCI drivers that can > "trigger" detection by the library via hotplug, the library could manage > things like persistent configuration, either separate desktops or > geometry of a complex desktop, etc... and eventually notification of > userland clients of mode changes. > > One reason for that is lots of monitors lie about their capabilities in > their EDID block, so we want "override" files. > > The kernel driver in this case doesn't need to be that much different > than the current fbdev's though, except that we want to move the HW > access for graphics commands to the kernel too, which basically turns > into merging the DRI driver and the fbdev. There is no need, I think, to > re-invent the wheel from scratch here, it would be a lot more realistic > to build on top of those existing pieces. 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. 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. 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. So moving mode setting to user space is not the end of the world. Everything will still work. This is more like a monolithic vs microkernel type of decision. All of the existing code is going to be reused (if we can figure out the licenses). I've already built a very messy prototype by moving the existing fbdev code to user space and it works just fine. I also called another little app which executed the VBIOS and reset secondary cards at boot via hotplug. I've convinced myself of the advantages of moving mode setting to user space, but maybe I've missed something that someone else will point out. But let's look at this as an engineering problem and try to come up with a robust, efficient solution. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 --- 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
Re: Current discussion about the future of free software graphics
> 1: Design must provide a mechanism for basic mode setting in a
> device independent manner from an application with user level
> permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY involved here. This is a sure way
to make sure Tungstengraphics has a income coming in. They want a monoply
on the linux graphics arena then fine they can have it.
---
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
Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
> I don't think that's a good idea: dri-devel is limited to the platforms that > have a working DRI implementation, while linux-fbdev-devel is also frequented > by people from platforms without DRI. > > And there we see a communication problem again: the DRI was started without > talking to fbdev people, IIRC... > > Please unite our forces! I agree here. I apologize for my behavior. --- 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
Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
On Tue, May 11, 2004 at 01:09:48PM -0500, sottek wrote: [...] Well said! We are all behind you. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
On Tue, 11 May 2004, sottek wrote:
> Also, we probably want to drop the communication down to just one
> list? I think dri-devel seems to have the widest group of subscribers.
I don't think that's a good idea: dri-devel is limited to the platforms that
have a working DRI implementation, while linux-fbdev-devel is also frequented
by people from platforms without DRI.
And there we see a communication problem again: the DRI was started without
talking to fbdev people, IIRC...
Please unite our forces!
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 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
[Dri-devel] Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't
never win this fight. There is MONEY involved here. This is a sure way
to make sure Tungstengraphics has a income coming in. They want a monoply
on the linux graphics arena then fine they can have it.
Are you completely without a clue? Nobody from TG is even participating
in this discussion (except a couple messages from Jens a week or so
ago). Why would you even say such a thing?
---
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
[Dri-devel] Current discussion about the future of free software graphics
Can we wrap this up the discussion and try to get to a consensus on
design requirements? I think most of the opinions are starting to
solidify enough to start hashing out the requirements and actual
design.
Also, we probably want to drop the communication down to just one
list? I think dri-devel seems to have the widest group of subscribers.
To start the ball rolling here is a few requirements that I have. We
can build up the list and veto as needed to try and get to a working
set.
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
2: Design must provide a mechanism for any number of driver dependent
extensions.
3: Design must provide a mechanism to allow the kernel to draw oops
or console messages to the screen in any mode.
4: Design must insure that user applications may not set the hardware
into an unstable state that could lead to lockup or damage display
devices.
5: Design must incorporate a bi-direction API versioning system. The
application must indicate the API version it is expecting first,
followed by the driver's reply.
And some that may require some discussion:
6: Design must provide a mechnism by which the driver can inform a
user application of acceptable modes that may later be applied to
hardware.
7: Design must provide a mechnism for user level applications to
use rendering features of hardware in a secure manner.
8: Design must provide a mechanism for multi-framebuffer and
multi-display per framebuffer devices to be controlled.
---
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
[Dri-devel] Re: Current discussion about the future of free software graphics
[ Please remove any subject tags when following up ] On Tue, 2004-05-11 at 04:20, Adam Jackson wrote: > > You only need to trust the user if the operation could have security > implications. [...] > mode setting isn't sensitive because changing the display mode isn't going > to stomp on kernel data structures or on the address space of other running > processes. You're assuming that the user programs a valid mode, but the proposed interface allows to program any combination of mode register values, of which valid modes are probably just a small subset, depending on the hardware. Combinations outside that set might cause unwanted effects such as lockups or even hardware damage, which is bad enough IMHO. System RAM access via DMA probably isn't an issue here with the hardware I'm familiar with, but it might be with others. > The mechanism _should_ be masked behind a library that abstracts away > the device and implementation details as much as possible so the user > (where here "user" equals X11 Classic, Y-Windows, Mesa Solo, whatever) > doesn't have to care, and also so each new user doesn't have to write > the same code again. Yes, an ALSA-style model is probably the way to go. I'm just pointing out that the interface between the library and the kernel probably can't be simply an unrestricted ioctl to dump a bunch of register values. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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
[Dri-devel] Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
> single kernel driver should muck with the hardware directly. However, > I'd like to point out again that it doesn't follow that the DRM and the > framebuffer device must merge to a single entity (which 'has to be' the > DRM if you ask some people, the framebuffer device if you ask > others...). E.g., they could both use the same mini-driver which deals > with the hardware. Let's try and keep our minds open to all possible > solutions. I agree. The disagreement is about where to put mode setting. > > register values. Finally the plug-in lib would use a private IOCTL to set the > > state into the video hardware. > > > > There are numerous pros and cons for both a both schemes. The user space code is > > swappable, easier to debug, and does not need to be run as root. > > It does, or the ioctl must verify the register data, which could require > about the same amount of code as computing it in the kernel in the first > place (possibly even more; the problem changes from computing a valid > combination of register values for a specific requested mode to limiting > the huge number of register value combinations to those that don't lock > up the chip or worse). I've pointed this out several times before, but > nobody has presented a solution yet. Will the userspace code live in a > daemon that runs as root? Or will only privileged processes be allowed > to change display properties? So in reality having mode switching would be just as expensive in userspace as having it in the kernel? --- 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
[Dri-devel] Re: [Mesa3d-dev] RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics
On Monday 10 May 2004 19:11, Sottek, Matthew J wrote: > >It does, or the ioctl must verify the register data, which could require > >about the same amount of code as computing it in the kernel in the first > >place (possibly even more; the problem changes from computing a valid > >combination of register values for a specific requested mode to limiting > >the huge number of register value combinations to those that don't lock > >up the chip or worse). I've pointed this out several times before, but > >nobody has presented a solution yet. Will the userspace code live in a > >daemon that runs as root? Or will only privileged processes be allowed > >to change display properties? > > I am in agreement with Michel on this point. > There is a privilege problem. > Either you trust the data coming from user-space to kernel-space > implicitly which means the user-space process now must be privileged, > or you don't trust user-space and you have to re-validate the data coming > into the kernel. Close. You only need to trust the user if the operation could have security implications. If your graphics card can use DMA to write to any point in memory, then you need to restrict that operation to root, otherwise a user can change the euid of a running process to 0. Or, the other way around, DMA reads could be used to read the shadow password file out of login(8)'s memory. Framebuffer and texture memory don't count as sensitive areas because the user can already write whatever he likes to them (perhaps through whatever authentication method your graphics system uses). Likewise mode setting isn't sensitive because changing the display mode isn't going to stomp on kernel data structures or on the address space of other running processes. Note that this is security from the kernel's point of view. How you limit access to your display is an orthogonal issue. X has no concept of segmentation, only authorization (modulo the Security extension, which by all accounts doesn't work very well anymore...). Presumably any future system will have/want to do authorization at some level, and will face the same issues X has now. > I have conceded that I am fine with a user-space mode setting API > as long as there is no imposed user/kernel split. For those who's chips > would require too much code to revalidate, they can just put the whole > mode setting in the kernel. I think we will discover that many of the > more advanced drivers will end up taking this route. Again, mode setting is a usability issue, not a security one. You can't violate the pagetable access control by changing timing settings on the video card. (With the possible exception of IGP-style chips where the framebuffer resizes to match the resolution; does this case even happen? Even in this case we could get away with the kernel knowing not to expand the resolution beyond a certain number of megapixels, or (speculation) running the framebuffer through the AGP aperture instead of directly on core.) That said, obviously the API is all that matters, and the user-kernel split is only mandatory to the extent that the hardware is able to circumvent the MMU to violate process separation and kernel protection. The mechanism _should_ be masked behind a library that abstracts away the device and implementation details as much as possible so the user (where here "user" equals X11 Classic, Y-Windows, Mesa Solo, whatever) doesn't have to care, and also so each new user doesn't have to write the same code again. Or am I missing something? > In the end I think this design is more complicated than is necessary. The > end goal should be to minimize privileged code, not just kernel code. When > you go with a split design you are forcing more privileged code than if > all the code lived in the same place. I agree with the second sentence, but not the rest. Consider OpenSSH's privsep implementation. Before, the entire daemon ran as root; now only a fraction. The number of lines of code running in as root (and thus needing auditing) was cut by a factor of ten, IIRC. If anything, proper separation _reduces_ the amount of code that runs in a privileged context. If the hardware details create security-sensitive code that has to live in the kernel, then it has to live in the kernel; so be it [1]. Putting code where it belongs cannot possibly count as bloat. - ajax [1] - For those unfortunate users who can't easily add kernel modules, something like the current X mechanism - exclusive mmap() of the hardware by a trusted userspace process - will have to suffice. They might sacrifice nice things like safe VT switching etc., but those are not bugs that free software developers can fix. Again, the API is all that matters, if a vendor has that they can fill in the implementation. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Eri
[Dri-devel] RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics
>It does, or the ioctl must verify the register data, which could require >about the same amount of code as computing it in the kernel in the first >place (possibly even more; the problem changes from computing a valid >combination of register values for a specific requested mode to limiting >the huge number of register value combinations to those that don't lock >up the chip or worse). I've pointed this out several times before, but >nobody has presented a solution yet. Will the userspace code live in a >daemon that runs as root? Or will only privileged processes be allowed >to change display properties? I am in agreement with Michel on this point. There is a privilege problem. Either you trust the data coming from user-space to kernel-space implicitly which means the user-space process now must be privileged, or you don't trust user-space and you have to re-validate the data coming into the kernel. The former doesn't buy you much. Now you have another root running deamon floating around to be a security problem. The latter's protocol and re-validation is difficult to the point of being a complete waste of effort. I have conceded that I am fine with a user-space mode setting API as long as there is no imposed user/kernel split. For those who's chips would require too much code to revalidate, they can just put the whole mode setting in the kernel. I think we will discover that many of the more advanced drivers will end up taking this route. In the end I think this design is more complicated than is necessary. The end goal should be to minimize privileged code, not just kernel code. When you go with a split design you are forcing more privileged code than if all the code lived in the same place. --- 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
[Dri-devel] Current discussion about the future of free software graphics
[ Apologies for the broad cross-post; I'd like to reach anyone potentially interested ] First of all, it should be fairly obvious to anyone that ideally only a single kernel driver should muck with the hardware directly. However, I'd like to point out again that it doesn't follow that the DRM and the framebuffer device must merge to a single entity (which 'has to be' the DRM if you ask some people, the framebuffer device if you ask others...). E.g., they could both use the same mini-driver which deals with the hardware. Let's try and keep our minds open to all possible solutions. I'd also like to comment on some points I noticed in the ksummit-2004-discuss archives: In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000388.html, Jim Gettys wrote: > In short, the X server would put a sequence of commands into a piece > of memory also visible by the graphics card, set up the DMA > transfer, tell it to go, and then continue setting up a second buffer, > and call into the UNIX kernel with the transfer address of the > second buffer, that transfer to be initiated at interrupt time > when the first buffer's commands had been processed; this then blocked > the X server, so it had good "interactive" behavior under many > circumstances. > > It may be that system calls are now cheap enough to do this rather than > having to do it in user space [...] Yes, that's basically what the r128 and radeon X drivers do when the DRI is enabled, and it's considerably faster than direct register banging. In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000391.html, Jon Smirl wrote: > The modelines would be passed into the plug-in libs which would turn them into > register values. Finally the plug-in lib would use a private IOCTL to set the > state into the video hardware. > > There are numerous pros and cons for both a both schemes. The user space code is > swappable, easier to debug, and does not need to be run as root. It does, or the ioctl must verify the register data, which could require about the same amount of code as computing it in the kernel in the first place (possibly even more; the problem changes from computing a valid combination of register values for a specific requested mode to limiting the huge number of register value combinations to those that don't lock up the chip or worse). I've pointed this out several times before, but nobody has presented a solution yet. Will the userspace code live in a daemon that runs as root? Or will only privileged processes be allowed to change display properties? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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
