Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Daniel, what's the status of fixing this?  The last we talked you were going to be looking into this as part of your input rework.

it's a substantial amount of work (at least as much as converting the xorg ddx was), so last i talked to the dmx guys, brian didn't have the time but said he might be able to do it, and i think alan said he might be able to as well.

Hmmm, except that the DMX guys are me on the output side, and Rik Faith on the input side.  My expectation, based on what we discussed, was that since you rewrote the input support in the server, that you'd be fixing the parts of the tree that you broke.  I hope this hasn't changed.

I'll ask Rik to see if he has any time to look into this.  Also, I talked with Peter Hutterer and he said that he have some time to look into it, but as he's trying to finish his thesis, I don't know if he will.

okay, i think that was just based off who'd committed recently (and a very rough recollection at that).  while most everything is indeed fixed, except for the input drivers which are on my todo list, dmx is such a large task that it would take an inordinate amount of time and prevent me from doing other input work (including xkb) and board work during that time, hence i was trying to see if other people could take it on first.

OK, and as I mentioned above, I'm also looking for people who know the input code (from one angle or another) and have a good chance to work out the issues.

BTW, this bug should block the release that the input rework goes into.

btw, if there's anything specific you want to know, just ask.  kinput.c is a pretty good example, basically your code looks like this.  throw away your custom event queue, and make sure you never generate your own xEvents by hand, when dealing with input events.  instead, have:

   int i, nevents;
   xEvent *events = xcalloc(sizeof(xEvent), GetMaximumEventsNum());

followed by one of:

   nevents = GetPointerEvents(events, pDev, MotionNotify, flags, 0, 0, 3, { x, y, z });
      flags is a bitmask; POINTER_ABSOLUTE specifies absolute rather than relative motion, and POINTER_ACCELERATE (only meaningful without ABSOLUTE) will, well, accelerate it.  for dmx you probably just want ABSOLUTE.  the arg after flags is a button arg, i think, and you don't want that.
   nevents = GetPointerEvents(events, pDev, ButtonPress, flags, n, 0, 0, NULL);
   nevents = GetPointerEvents(events, pDev, ButtonRelease, flags, n, 0, 0, NULL);
      n is the button number.  change (0, 0, NULL) to (0, 3, { x, y, z }) if you have the co-ordinates for this event.  same flags as above.

   nevents = GetKeyboardEvents(events, pDev, KeyPress, n);
   nevents = GetKeyboardEvents(events, pDev, KeyRelease, n);
      n is the keycode.

followed by:
   for (i = 0; i < nevents; i++)
        mieqEnqueue(events + i);

and that's the gist of it.  GetKeyboardValuatorEvents exists for when you want to send key events with co-ordinates (GetKeyboardEvents is just a special case of GKVE), and there's also GetProximityEvents, but I don't think I've tested that.

you can also get rid of any custom motion history stuff, and just use mi's motion history.

Kevin - I might be forced into looking at this soon, but what's the status on your end ??

(In reply to comment #8)
> Kevin - I might be forced into looking at this soon, but what's the status on
> your end ??

Sadly, I continue to have very little to no time.  Also, I know the output side well, but on the input side I was only involved at the design level, so I'm having to learn the code as well as the new input code, which is going very slowly.  Rik is very busy with work, etc. right now, so he won't have any time for a while.  So, no real progress on this front.

You might also want to ask Peter Hutterer, who expressed interest in looking into making DMX work with the new input code at XDevConf.

I'll take a look at this.  I don't know anything about X input but I'll see what I can make of it.  I'll probably have to pester people with questions...

i think c#7 should be a pretty good summary of what needs to be done, but i'm of course happy to answer any questions anyone has doing the conversion.

Just a status update: as of now, Xdmx compiles and runs for the most part, but there's some strangeness.  If you click a mouse button on any screen/backend but the first, the mouse pointer warps to the center of the screen.

I'll try to get back to this next week.  In the mean time, feel free to try it out and debug the glitches.  Note, there's quite a few ErrorF() calls and #if 0 / #endif code blocks that'll have to be removed eventually, but not until after things work.

Update: DMX seems to be working OK now.  Only very light testing so far and lots of debug code still in place.  Might be good to have someone else test to confirm things though.

I seem to be stuck on one thing.  The function dmxCheckFunctionKeys() is called for every key press/release event.  This is where we check if Ctrl-Alt-Q is being pressed (or Ctrl-Alt-f/g) to exit DMX.  For some reason, dmxLocal->pDevice->key->state field never indicates that any modifier keys are pressed.  I haven't been able to figure out the problem.  I think I need some help with this.

People depend on Ctrl-Alt-Q for exiting DMX so I think it's important that this is fixed.

In the absence of an active maintainer to fix issues before release, given that this server is disabled by default, clearing blocker status.

I found a work-around for the Ctrl-Alt-Fn key problem back in April (see hw/dmx/input/dmxevents.c::dmxCheckFunctionKeys())

AFAIK, the Xdmx server is in working condition.  Someone should probably try building it in its current state just to be sure.  I don't have time right now.

Builds fine for me.