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-
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
