--- Michel Dänzer <[EMAIL PROTECTED]> wrote:On Sat, 2003-08-09 at 02:24, Mike Mestnik wrote:--- Michel Dnzer <[EMAIL PROTECTED]> wrote:
On Fri, 2003-08-08 at 04:27, Mike Mestnik wrote:
I have made patches for DRI, but thay never seam to get maintained.
What are those patches?
I added devfs support, and I also wrote some initail Hot-Plug support. However after the fifth week of trying to keep my DRI relitivly new I gave up.
I guess none of the DRI developers are particularly interested in these topics; you could try getting them into a kernel tree?
I'd still have to merge when/if I wanted to run bleding edge DRI.
I looked though the list archives, and I could not find any of these patches. I've always been a fan of devfs, so I think at least that would be interesting. Could you send them to this list? I'm sure that someone here (Alan, perhaps?) would be able to review the hot-plug support.
The overall goal was to unify initalation, having the DRM hand X and DRI the driver name, device ID and other config info. The list of PCI devices would ony need to be walked once by the kernel. This would shave off a fue CPU clocks at startup. I run a tight ship, I don't generaly like wating a fue hundreths of a second for my computer to boot up.
In doing so I hoped to find more areas where the startup could be speed up.
I don't see how this could eliminate PCI device probing in the X server, and I doubt it contributes significantly to startup time anyway.
The Idea is Userspace gets PCI id and any other info it might need from a kernel datastore(just pointers to the real data). So insted of "for ech device where ID=x or y or z" you dereferance a pointer in kernel space and pass the value to user space(ioctl?). The kernel dose the for ech device part on modual load(Hopfully once per reboot).
The other thing I'd like to do is to combine the fbdev and the drm into a single char device, if posible.
That's a dream, but it is largely impractical. The biggest problem that I see is that the DRM is portable to other platforms (i.e., the various BSDs), and fbdev is not. Another issue is closed-source drivers. If fbdev and DRM were merged, that would preclude having the fbdev driver and a close-source DRM module being loaded at the same time. That may not impact many people, but those that were affected would complain very loudly.
I understand thet core DRI developers can't realy spend time doing code cleanups like this, because thay are so trivial. The problem is every time I want to do a cvs update I end up haveing to do a merge. This was a bigger issue when R200 support was just being added, now it's less but will still be a problem.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
