Current discussion about the future of free software graphics

Current discussion about the future of free software graphics

[sottek]

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

Re: Current discussion about the future of free software graphics

[James Simmons]

> 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

Re: Re: Current discussion about the future of free software graphics

[Ian Romanick]

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

Re: Re: Current discussion about the future of free software graphics

[Jon Smirl]

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 <benh@kernel.crashing.org> 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
jonsmirl@yahoo.com


	
		
__________________________________
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

Re: Re: Current discussion about the future of free software graphics

[Richard Smith]

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

Re: Re: Current discussion about the future of free software graphics

[James Simmons]

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
> Linux-fbdev-devel@lists.sourceforge.net
> 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

Re: Re: Current discussion about the future of free software graphics

[Geert Uytterhoeven]

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

Re: Re: Current discussion about the future of free software graphics

[James Simmons]

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

Re: Re: Current discussion about the future of free software graphics

[Geert Uytterhoeven]

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

Re: Re: Current discussion about the future of free software graphics

[James Simmons]

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

Re: Re: Current discussion about the future of free software graphics

[Richard Smith]

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

Re: Re: Current discussion about the future of free software graphics

[Richard Smith]

Somehow this dosen't appear to have made it the first time.  Apologies 
if 2 of these show up.


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

Re: Re: Current discussion about the future of free software graphics

[James Simmons]

> 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

Re: Re: Current discussion about the future of free software graphics

[Geert Uytterhoeven]

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

Re: Re: Current discussion about the future of free software graphics

[Nicolas Souchu]

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 - nsouch@free.fr - nsouch@FreeBSD.org
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

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

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

Re: [Dri-devel] Re: Re: Current discussion about the future of free software graphics

[Keith Whitwell]

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

Re: [Dri-devel] Re: Re: Current discussion about the future of free software graphics

[James Simmons]

> 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

Re: [Dri-devel] Re: Re: Current discussion about the future of free software graphics

[Keith Packard]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]


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



[-- Attachment #2: Type: application/pgp-signature, Size: 228 bytes --]

Re: Current discussion about the future of free software graphics

[Alan Cox]

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

Re: Current discussion about the future of free software graphics

[Geert Uytterhoeven]

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

Re: Current discussion about the future of free software graphics

[James Simmons]

> 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

Re: Current discussion about the future of free software graphics

[Nicolas Souchu]

On Tue, May 11, 2004 at 01:09:48PM -0500, sottek wrote:

[...]

Well said! We are all behind you.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
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

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

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

Re: Current discussion about the future of free software graphics

[Egbert Eich]

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

RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

[Sottek, Matthew J]

>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

Re: RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

[Adam Jackson]

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, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

[ 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

Re: Current discussion about the future of free software graphics

[James Simmons]

> 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

Current discussion about the future of free software graphics

[Michel Dänzer]

[ 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