xf86EnableIO & ExtendedEnabled vs. the input thread
Alan Coopersmith
alan.coopersmith at oracle.com
Sat Feb 16 01:00:04 UTC 2019
On 01/31/19 07:23 AM, Adam Jackson wrote:
> On Wed, 2019-01-23 at 14:22 -0800, Alan Coopersmith wrote:
>> Is there any reason we just don't drop ExtendedEnabled altogether and
>> just always pass the calls through to the kernel? That'd leave us
>> still needing to call xf86EnableIO() in the input thread on Solaris,
>> unlike Linux, but that's more sensible than forcing a DisableIO()
>> first just to reset the ExtendedEnabled state.
>
> I can't think of a good reason to track ExtendedEnabled, no. All of the
> implementations look like they're idempotent (though I had to read the
> weird Linux ppc thing twice to be sure). The ExtendedEnabled logic
> itself seems to predate XFree86 4.0, which is back far enough in the
> dark ages that I don't think we'd ever find a useful changelog for its
> motivation. I say nuke it.
Okay, I'll do that - but that then leaves the problem of how to enable it in
the input thread, since the input thread is in the core/shared X server code,
but needs to call a routine in the XFree86 DDX.
My current unclean solution is:
index 97e59d21f..8c8bf090a 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -39,6 +39,10 @@
#include "opaque.h"
#include "osdep.h"
+#ifdef __sun
+#include <dlfcn.h>
+#endif
+
#if INPUTTHREAD
Bool InputThreadEnable = TRUE;
@@ -326,6 +330,16 @@ InputThreadDoWork(void *arg)
pthread_setname_np ("InputThread");
#endif
+#ifdef __sun
+ {
+ Bool (*enableIO)(void) = (Bool (*)(void))
+ dlsym(RTLD_PROBE, "xf86EnableIO");
+
+ if (enableIO != NULL)
+ (*enableIO)();
+ }
+#endif
+
ospoll_add(inputThreadInfo->fds, hotplugPipeRead,
ospoll_trigger_level,
InputThreadPipeNotify,
but I'm guessing instead we should have some sort of callback or ddx-specific
initialization called from inputthread, that happens to be an empty stub
everywhere but the xf86 ddx for Solaris.
Thoughts on that?
Thanks,
-alan-
More information about the xorg-devel
mailing list