>>>> So, I'm wondering if anyone knows what might be behind this, or
>>>> has any suggestions for something to try, or the like. [...]
>>> [...syscall trace...]
>> At present I don't even know whether the slowdown is in a syscall,
>> though it seems likely since a 9.x X server talking to the same
>> hardware without kernel involvement *shouldn't* be any slower.
> But isn't it precisely the problem? X was running purely as user
> level, but with DRM now, the support is partly in the kernel.
My English was ambiguous.
When I wrote the above quote ("though it...any slower."), I meant, it
seems likely that the issue is in a syscall, because *if* the 9.x X
server were talking to the hardware without kernel involvement, ie, if
it weren't using syscalls, it shouldn't be any slower under a 10.x
kernel.
I think the 9.x X server uses kernel DRM interfaces, because it seems
to believe the kernel's idea of the screen's size, even if it's wrong.
(Specifically, booting with no screen attached, then attaching a
monitor, then starting X, gets X running at the resolution the kernel
defaulted to, not the actual monitor's resolution.)
> So---I may well be wrong---it seems to me that even a 9.x userland
> will rely on a 10.x X kernel part.
Yes, it seems likely to me too, for the above reasons.
> It may be simpler to backport the hardware support from 10.x to 9.x
> than to try to fix X/DRM... I hope I'm wrong...
Possibly. I haven't yet looked at it with that in mind. But, isn't
9.x about to go out of support? That would be another reason for them
to want to switch to 10.x, though from what I gather this is pretty
close to a showstopper for them.
I'm working towards installing 10.x on a work machine I have here at
home currently running the 9.x system, similar (I think) to their
systems, to see if I can reproduce it here where I can look at details.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML [email protected]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
