mouse/keyboard events getting delayed in games

[divVerent]

At least in the game Nexuiz, mouse and keyboard input sometimes gets "queued up".

As in: I click around wildly in the menu (this seems to "invite" the bug fast). After that, I can click options, and they won't activate until I move the mouse a bit. Or, I move the mouse right, stop for some seconds, then move it DOWN - and it still goes RIGHT a little.

I debugged this a bit in the Nexuiz source and came to the conclusion that the event loop does not even SEE these events, so this probably can't be a bug in Nexuiz:

in vid_glx.c, the function HandleEvents() is just a simple loop of the form:

        while (XPending(vidx11_display))
        {
                XNextEvent(vidx11_display, &event);
                ...
        }

Inside this loop, there is no "return" or "goto", so this must handle all events that are queued up. Also, I get the very same problem when using the SDL build of Nexuiz, which uses a completely different event loop, namely a while(SDL_PollEvent(&event)) loop, with which there should be nothing wrong.

I managed to work around this problem by switching away from evdev to mouse, by adding these lines to xorg.conf:

Section "ServerFlags"
        Option "AutoAddDevices" "False"
EndSection

Section "InputDevice"
        Identifier "mouse"
        Driver "mouse"
        Option "CorePointer" "True"

        Option "Emulate3Buttons" "False"
EndSection

Section "InputDevice"
        Identifier "kbd"
        Driver "keyboard"
        Option "CoreKeyboard" "True"

        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "de"
        Option "XkbVariant" "nodeadkeys"
EndSection

This shows that the problem must be evdev related.

As I have this report open now, I'll submit it, then remove that workaround from my xorg.conf and try to reproduce it with DGA disabled.

[lspci]
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
     Subsystem: Micro-Star International Co., Ltd. Device [1462:7185]
05:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce 7600 GT] [10de:0391] (rev a1)
     Subsystem: Giga-byte Technology Device [1458:3427]

[divVerent (divverent)]

Yes, when turning off DGA (in the GLX build, by "set vid_dgamouse 0" on the game's console, in the SDL build, by doing "export SDL_VIDEO_X11_DGAMOUSE=0" on the terminal before starting Nexuiz), the problem goes away.

This however is not an option for first person shooter games like Nexuiz, as the whole point of using DGA is to disable the mouse acceleration that is done otherwise, which massively interferes with aiming in such games (and this is the case both with the SDL and with the GLX build). Or is there an alternate interface Nexuiz could use in the "non-DGA path" to achieve the same result?

[divVerent (divverent)]

I added code to the DarkPlaces engine to control mouse acceleration even in non-DGA mouse using XChangePointerControl. Affected users can compile a current engine from svn, and run it with the option +vid_dgamouse 0.

But should Nexuiz really turn off DGA support just for Ubuntu? On Fedora 9, this problem does not happen even with evdev. No idea why.

[divVerent (divverent)]

The bug is identical to what "Mad Merlin" gets in http://forums.gentoo.org/viewtopic-t-648464.html, but that page contains no further details on its source.

[Bryce Harrington (bryce)]

[This is an automated message]

Hi divverent,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[divVerent (divverent)]

Only xorg.conf customizations are those already mentioned above. The xorg.conf otherwise is exactly like how it was after install and enabling of the nvidia driver using "jockey".

[divVerent (divverent)]

Actually, no, no customizations are done, the customizations were only for getting rid of the bug. The file now is, when reproducing the bug, an unmodified xorg.conf.

[divVerent (divverent)]

There are no xorg.0.log messages when the problem happens. Full log file attached.

[divVerent (divverent)]

Setting back to "New" as I provided the info that was asked for.

[Bryce Harrington (bryce)]

Could this perhaps be a bug in SDL rather than in X?
Can you reproduce this behavior in any non-SDL applications?

[divVerent (divverent)]

The "glx" driver of the DarkPlaces engine - which is what I am describing above - does not use SDL in any way. DarkPlaces can be compiled both with and without SDL usage. IIRC the version distributed with Ubuntu is the SDL one, while I am preferring the non-SDL build.

The problem however ALSO appears with SDL games (e.g. Quake 3, Unreal Tournament), and for SDL games a workaround of exporting "SDL_VIDEO_X11_DGAMOUSE=0" and "SDL_VIDEO_X11_MOUSEACCEL=1/1/0" works. For non-SDL games that use DGA, such a workaround does not always exist.

[Dmitry (dmitrykos)]

Got same problems when installed Ubuntu 8.10 Desktop. The evdev interface seems to have some problems, it is only related to mouse/keyboard, I do not know if it matter what are they (Logitech Bluetooth Desktop 5000). My library that work with input devices stopped processing mouse/keyboard event as actually no events are read from opened event device file descriptor. On the other hand my 2 joysticks (joystick, gamepad) are both working as expected.

Earlier I had Ubuntu 8.04 Server installed and there were no such problems, all devices were readable.

::ioctl does return device setting and etc. but ::read does not read any events from keyboard or mouse, I assumed is there possibility that some of core parts of Ubuntu did EVIOCGRAB on these devices, this could be a cause for such behavior.

All devices including succesful joystics are read by single method:

template <class _TyInput>
static inline uint32 read_events(CDeviceNixLX::xctrl_t *device, _TyInput *events, uint32 count)
{
 const int read_total = ::read(device->xobj, events, (count * sizeof(_TyInput)));
 if (read_total < 0)
 {
...

[Bryce Harrington (bryce)]

Don't file X bugs against xorg if they're already filed against xorg-server, unless there really is something that needs done in the xorg package.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi divVerent,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 295912

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 295912 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/295912

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.