From: Jon S. <jon...@gm...> - 2004-09-04 22:08:14
|
On Sat, 04 Sep 2004 14:31:16 -0700, Eric Anholt <et...@lc...> wrote: > You mean all the rearchitecting you've been doing to make the driver > behave like it actually attaches to specific device? Yeah, BSD has > wanted that since the very beginning. I just never implemented it > because I didn't want to make more diffs compared to Linux. > > As far as hotplug, well, I've never used that feature on Linux and > haven't looked in to it. When I think of "hotplug" I don't see anything > that couldn't be implemented using FreeBSD's current driver model with > only minor changes. > > I personally think that these major architectural changes you're looking > at doing would be best done outside of our stable DRM (head) branch in > DRI CVS. I'm not expecting FreeBSD to adopt them, because our > requirements are different (debugging of panics is supposed to be done > over serial console or through dumps. We don't generally have an fbdev > equivalent, and though some individuals have produced mostly-complete fb > devices, nobody has really been interested). If it gets to the point > that Linux wants to move to the fb-ified DRM and it's going to become > the stable version, I would say let's deal with those issues then. Or > just stick your GPL code in drm/linux and not worry about BSD, if it can > be developed in head without disrupting (Linux) users. The major DRM changes are all stemming from problems on Linux. 1) DRM attaching directly to device 2) hotplug 3) stopping device driver multi-tasking 4) no universal video mode setting API The only reasonable solution to #3/4 is to merge DRM/fbdev. I have been burnt several times doing major changes on branches. What inevitably happens is a) lots of code drift between the trunk and the branch and b) refusal to take the big patch when it shows up. I have learned instead to get general acceptance of the proposed architecture. This architecture has been posted everywhere and discussed in detail at OLS: http://lkml.org/lkml/2004/8/2/111 After getting acceptance write the pieces one at a time and get them accepted into the kernel. DRM is already getting considerable kickback from kernel developers for the size of the patches coming in, doing this work on a branch would make it even worse. If there are flaws or better ways to achieve the proposed architecture please let me know. With X on GL the 2D XAA driver disappears. Since the 2D XAA driver was supplying the mode setting code we need another solution. Attached is the mode setting scheme discussed at OLS. It supplies a universal API for handling devices that do mode setting in all different ways: user space, vm86, in kernel. ------------------------------------------------ At OLS we talked about a system like this: 1) user owns graphics devices 2) user sets mode with string (or similar) format using ioctl common to all drivers. 3) driver is locked to prevent multiple mode sets 4) common code takes this string and does a hotplug event with it. 5) hotplug event runs in root context in user space 6) mode is decoded and verified, this may involve a little process that maintains the DDC database and reads a file of legal modes. Other schemes are possible. 7a) mode is set using VBIOS and vm86, signal driver mode is set 7b) the register values needed to set the mode are passed into a root priv ioctl. 8) driver is unlocked. In this model all of the verification happens in user space. If you want to set modes other than the ones from DDC you have to add them to the config file. There is no need for DDC support and mode verification in the kernel. To give credit this is Alan Cox's design. -- Jon Smirl jon...@gm... |