On Thursday 01 June 2006 02:19, Jon Smirl wrote:
> On 5/31/06, Antonino A. Daplas <[email protected]> wrote:
> > > 4) Some things are so tiny it is pointless to move them to user space
> > > and they need root to work. Things like screen blank, set the hardware
> > > cursor, set the cmap, etc. I think these are best implemented as
> > > additions to the DRM driver.
> >
> > These small things (cmap, blanking) are sometimes difficult to do, and
> > the driver is not always right about that. A user helper may be needed.
> > vesafb in x86_64 may not be able to set the cmap properly without calling
> > out to the BIOS.
>
> Call out to user space if it is complex. But it only takes few lines
> of code to to these things on a radeon.
I'll be working with Tony on a lot of the fbdev side of things. Hopefully we
won't run into problems providing for backwards compatability.
> > > 7) Since there isn't much left to a device specific fbdev driver after
> > > you push mode setting out to user space, I would just add the
> > > remaining functions to the device specific DRM driver. But that would
> > > be 'evil' since it merges fbdev and DRM.
> >
> > Actually, there's no need for a merge as there is nothing in DRM that
> > is absolutely needed by fbdev or the other way around, as long as
> > console acceleration is disabled. In-kernel fbdev drivers may not even
> > be necessary.
>
> Something needs to bind to the hardware, that code is in the device
> specific fbdev drivers currently. The fbdev drivers also contain those
> small functions I mentioned like cmap, cursor, etc. Some of the fbdev
> drivers also contain initialization code.
>
> If fbdev is eliminated the DRM code will need to provide a compatible
> fbdev device in user space for legacy apps. It makes sense to get that
> code from fbdev.
I've been talking with Tony and this seems to be the direction he'd like to
take the Kernel. While I'd like to keep the full complement of fbdev drivers
in the kernel for the embedded people to use (or not) as they please, this
might not be a good idea.
> Any concerns about having two device nodes for a single piece of
> hardware, fb0 and dri0? Since dri0 has a single user it may be
> possible to rework its IOCTLs to use the fb0 device.
>
> As part of multiuser support you need to make one device per head
> instead of one device per card. Each independent user needs their own
> deivce to control.
I was thinking that the dri? nodes could redirect fb specific IOCTL's
internally and still maintain the two device nodes. This is actually part of
not breaking anything, since a lot of legacy apps will look for the dri* or
fb* nodes.
And yes, providing a device per head is something that needs to happen, if
just to make things like a multi-head Radeon easier to configure and bring up
both heads on under X.
As to having seperate devices per user - the only cases this would be really
required are:
1) Multiple users logged onto different VT's
2) Remote users doing server-side acceleration of graphics
For #1 there is no need for seperate devices, since both users are using the
same display and input methods (unless configured different - say with
multiple heads and input devices, in which case the second head would already
have a node available for it).
For #2 I have no real solution. Personally I think that most of the drawing
commands that can be accelerated should be left to the remote client. As far
as a remote client wanting sever side rendering and acceleration... This can
use the same device node and a seperate rendering buffer.The driver itself
*should* be able to handle accelerating offscreen and oinscreen rendering at
the same time.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
