Keyboard trouble on Linux box

[Leshiy]

Hi there, I have been messing about with lwjgl and jpct on my linux box and found curious little problem. when I switch to OpenGL mode in jpct and use lwjgl keyboard it polls nothing from my keyboard.

It gets the number of keys (126) but registers no input from keyboard. Mouse works fine it regixters and sees its position but not keyboard.

I had a look quickly at the code because it is really bugging me now. There is bit where readBuffer is created

Code:

private static void create(InputImplementation impl) throws LWJGLException {
if (created)
return;
if (!initialized)
initialize();
implementation = impl;
implementation.createKeyboard();
created = true;
readBuffer = ByteBuffer.allocate(EVENT_SIZE*BUFFER_SIZE);
reset();

and then reset to 0 in last line there. Is that meant to be like that? Could that be my problem? Or is there something else wrong? I create the Keyboard with create() method and I get no exception and when I get out key count I get no exception either.

[Matzon]

reset in itself shouldn't do any harm. I am not familiar with jpct. Does it use the Display or AWTGLCanvas ?

[Leshiy]

reset in itself shouldn't do any harm. I am not familiar with jpct. Does it use the Display or AWTGLCanvas ?

I had a bit deeper dig in to this. Jpct seems to have nothing to do with it. It uses Display, it successfully creates display. Also when it creates display it creates controls, and creates keyboard. But when I check with Keyboard.isCreated() it returns false, so I have to create it again. Should that really be happening?

Than it creates keyboard successfully again and gets some linux implementation of it. Now because it works on my other Linux box I got a feeling that it gets the wrong implementation of keyboard for that hardware, tries to use it to read the events from keyboard and fails, well rather read buffer remains empty so I poll nothing and throws no exception.

All of the info I got from debugger in eclipse. I tried pulling just Keyboard out in to my source but had limited success and didn't want to drag all of the lwjgl code out, understand it and compile it. 

[raft]

i have problem with keyboard on my linux box too. i can create the keyboard and receive most keyboard events but not the control key event. Keyboard.isKeyDown(left-right control) never returns true. pressing/releasing control key never generates an event either.

this is a fedora 4 linux laptop, with only left control key. awt itself properly generates control key events. i've also tried the keyboard test demo, it doesnt capture any control key events either (as i can see from console)

any ideas why this may happen ?

thanks
r a f t

edit: keyboard test demo succesfully captures control key events on win xp on same machine

[elias]

Which version of LWJGL are you using? Could you try the latest (1.1.4 and 2.0a2) if you haven't already? Leishy: Which linux distribution and version are you using, and could you try the standard KeyboardTest from lwjgl? raft: I can't reproduce the problem here, on a Ubuntu 7.10, so to get any further, you'll need to dig down yourself. The interesting code is in java (for example, see if LinuxDisplay.processEvents() gets any events when pressing ctrl, and if so, why they don't end up in KeyboardTest) so you should be able to compile a custom version of LWJGL (or use a debugger).

 - elias

[raft]

i'm using 1.1.4. 2.0a2 results the same.

the reason turned out to be the mouse pointer displayed when control is pressed. that option can be found at: DesktopMenu | Preferences | Mouse | Highlight pointer when Control is pressed. when it's disabled all is fine.

i've added a line to LinuxDisplay.processEvents() to print event_buffer.getType(). it prints nothing when control is pressed but prints some mixture of 15 and 12 (expose) i dont now what 15 is. i've also noticed that similar sequence is printed when switching between windows. i guess it maybe something like when that cursor is displayed, lwjgl thinks window has lost focus and discards events until focus is returned

btw, the source zip isnt buildable as it is. one needs to copy jinput.jar to libs folder

hope this helps
r a f t

[wolf_m]

Wow, one of those subtle annoyances right there. Thanks, Desktop Environment(tm). Great job. Should probably be reported as a bug to the DE developers.

Is that Gnome? KDE? I don't know the default Fedora DE and don't know what kind of option you're referring to there.

[raft]

it's KDE. this is useful option indeed, you know there are times you lose mouse cursor at the screen. press control and see the big marker to find it

i believe this should be handled in LWJGL as awt/swing handles control events succesfully

[Leshiy]

Leishy: Which linux distribution and version are you using, and could you try the standard KeyboardTest from lwjgl?
 - elias

Sorry about late reply.
I just ran the test properly. I got Window with Game title, black background and white thing there. I pressed all of the buttons on keyboard got nothing.

I also ran MouseTest to make sure and that works fine with colourful stuff.

Running:
System Fedora Core Ent 5
KDE: 3.5.4.11-el5 Fedora-Core
Kernel: 2.6.18-36.el5

[elias]

Odd. I'm afraid you'll have to dig deeper to tell why no events are reported. Try outputting from LinuxDisplay.processEvents to see if anything at all arrive, and if so, why you're not getting the events from Keyboard.

 - elias

[Leshiy]

Well I had a look more and it is really tricky to debug the code I didn't write or actually understand. The main problem is there are bunch of final declarations that I can't track modifications of in eclipse. Is there debug flag of sorts that I can pull out more info from.

processEvents is called all the time because LinuxDisplay calls the update() on mouse and keyboard so I cant create keyboard event becasue it constantly updates mouse and display.

[elias]

In processEvents, "event_buffer.nextEvent(...)" will fetch the next event from X (if any), so you can just put a System.out.println there to see if anything arrives when you press a button. If no events have arrived since the last call to processEvents, the while (... > 0) should not be entered.

 - elias