xf86EnableIO & ExtendedEnabled vs. the input thread

[Alan Coopersmith]

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-