> With a properly designed kernel driver the X server does not need
> to map the hardware into user space and run as root.
How do you efficiently control the hardware then without incuring the overhead
of user/system transition on ioctl's? How many iotcl's and at what granularity
are you suggestin
these fixes "upstream". Full explanation in the bugzilla referenced.
http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399
--
John Dennis <[EMAIL PROTECTED]>
---
This SF.Net email is sponsored by: IBM Linux Tutorial
lace the kernel drm drivers as well? If so
do they manage AGP themselves, or do they use the systems agpgart
driver? Do they replace the systems agpgart driver?
--
John Dennis <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: SF.ne
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an XFree86
I've been trying to track down a DRI client and server deadlock
problem. I think I now know the problem, I'd appreciate it if others
could confirm this is a bug or if I have a misunderstanding.
This is the scenario:
1) Client takes heavyweight lock via ioctl, lock now has DRM_LOCK_HELD
bit or'ed
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ]
I'm trying to debug a hung X server problem with DRI using the radeon
driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at
the moment I don't see anything architecture specific about the problem.
The symptom of
send me a pointer to something that
documents it. I'd like to know why one implementation is picked over the
other, are there version dependencies, why it exists as parallel to drm
and what its trying to fix.
Thanks,
John
--
John Dennis &l
