New DRM model

[Jon Smirl]

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> What I don't like in your whole discussion from the very beginning is
> that you seem to focus on your specific idea & setup leaving everything
> that doesn't fit in your scheme aside, which ends up beeing a fair bit.
> 
I'm only working on this by myself. I welcome help covering the areas I'm
missing.

> I'm also not sure it's realist to remove any fb. access at this point...

The problem here is that my DRM driver and FB are both claiming the same PCI IDs
and the kernel will only let one load. Same for putting entries into sysfs. The
kernel is simply not designed to support two device drivers trying to control
the same piece of hardware.  So I'm not saying remove fb, I'm saying that you
have to choose, FB or DRM. They only reason the sharing works right now is
because DRM runs in stealth mode and plays with all of the hardware without
letting the kernel in on the fact. 

My code can't run without hotplug and sysfs so I'm forced to claim the same PCI
IDs that FB is claiming. This is what forces the choice.

I also recognize that FB serves a useful purpose. So I'm trying to modify DRM to
support the areas that FB serves. That's what made me come up with the idea of
booting console to user space and eliminating the TTY/VC stuff. The TTY/VC is
single user by design -- all of my system have multiple video cards. User space
console could easily support a keyboard for each screen allowing multiple users.
I thought this might be valuable in a class room/internet cafe type setting.

> > I slowly working through all of the places where Xfree touches the hardware.
> I
> > haven't come to a conclusion on this yet -- whether to use IOCTLs or a
> daemon.
> > I'm not too enthused about adding 100 IOCTLs if that's what it takes.
> 
> ioctl's are evil anyway. They should disappear. The normal flow of
> commands should go through a read/write interface instead and the
> format be done properly enough to avoid the 32/64 bits conversion,
> which is one big issue with the current DRI on 64 bits platforms
> with 32 bits userland.
> 

It would be fun to convert DRM to a read/write model. Maybe someone else will
chip in with that piece of work. How about using IDL to describe the interface
and using the IDL compiler to generate the stubs? Code for serializing the IDL
data area exists in Mozilla's xpcom library.  A great big 2.7 project could be
to convert everything from IOCTLs to marshaled IDL.

> Ben.
> 
> 

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html