Poll Input

Archives Forums/Linux Discussion/Poll Input

Richard Betson(Posted 2012) [#1]
I am having some issues with input from the mouse and keyboard. In scanning the forum here I really have found no solutions. The BlitzMax demos seem to work fine so it has to be something I'm doing.

Are there some issues in Linux that make polling ( KeyDown()/KeyHit()/MouseDown() ) input different then in Windows. My application polls input every 1/30 of a second and works fine in Windows.:)

Input is wild and unpredictable and keys for example get reported down when there not, after being pressed once. In this example the the right arrow is pressed once and then it will keep reporting it down. It does the same thing on the mouse buttons.

This sort of reminds me of this problem with polled input from mouse and canvases. Although I'm not using MaxGUI in the application.

If you have come across this problem or have a solution let men know.


Richard Betson(Posted 2012) [#2]
I'm thinking this might have something to do with MaxGUI. It turns out that I did have some MaxGUI code in my project. Once I removed it and the input problem seems to have disappeared. The intresting part is that I was only initializing a Tgadget variable, that's it.

I guess MaxGUI is a little touchy or has an issue.

**-=> Edit - Just Importing the MaxGui module is enough to cause the problem. Bug? It also does it with the sample demos.

Last edited 2012


dawlane(Posted 2012) [#3]
The MaxGUI has many problems and it hasn't been updated for ages.
It would be a good idea to post some code so others can test it on their systems as it could be Linux operating system specific.


skidracer(Posted 2012) [#4]
I'd be tempted to blame MaxGUI also.

MaxGUI was never designed or tested to work along side standard brl Graphics windows. On Linux both modules hook into xwindows event streams in ways that should have been reviewed by an xwindows expert but I'm still yet to meet one in the flesh.

Last edited 2012


Richard Betson(Posted 2012) [#5]
Hi,

I guess the obvious solution here is to breakout the MaxGUI into a separate application to avoid conflicts. In my case this is a little difficult as my project engine is designed to support a game and an editor. But I did resist heavily using MaxGUI in my game engine, so doable.


It would be a good idea to post some code so others can test it on their systems as it could be Linux operating system specific.

Well, you could use the 'FirePaint' example and add"
Import MaxGui.Drivers

On a small application like 'FirePaint' you will have to run it a few times before it will (randomly fails) start to fail on input. On my larger projects it fails right away.


in ways that should have been reviewed by an xwindows expert but I'm still yet to meet one in the flesh.

I hear they keep them in an underground government lab. :)

Last edited 2012


Richard Betson(Posted 2012) [#6]
I'm also not getting KeyHit()to report the 'Insert' key. I'm not using MaxGUI so that is not effecting the result. Anyone else have the same problem?


skidracer(Posted 2012) [#7]
you could try messing with brl.mod/system.mod/system.linux.c

the function to convert xwindow key events to blitz keycodes is called int getxkey(XEvent*) starting at line 278


dawlane(Posted 2012) [#8]
I wrote a small bit of test code and for some reason Insert is being mistaken of the C key.

EDIT:And looking at the getxkey(XEvent *event) function. I think I can see the reason why.
Edit Skid: Do you think it would be a lot of hassle to setup/use the actual keysym defines?

Last edited 2012


dawlane(Posted 2012) [#9]
Well did a bit of tinkering and got some of the keys working. I would post the code but I can't remember if we can post modifications to brl.mod.


Richard Betson(Posted 2012) [#10]
I wish we had a way to commit changes to Brl code. With Mark busy with Monkey I'm not sure any fixes will get into the BlitzMax release. Are these new bugs or is it that no one is really using BlitzMax on Linux? IMHO Linux is going to bump up in market share in the next few years and is already starting to closing on Mac in browser OS percentage ( http://www.w3schools.com/Browsers/browsers_os.asp ).

@dawlane

I think we can as Mark changed the licensing for BlitzMax. I'll try to find the post. Skidracer would know though. :)


dawlane(Posted 2012) [#11]
Max on Linux has always been the poor relation to the others and gets very few fixes. And I'm surprised that nobody noticed the mistake in getxkey. The key gets loaded by XLookupkeysym and is only using the lower 8bits.
If you look at the code in getxkey, you will see the first line checks for values 96 to 126 the if you look abit further down you see the the code for insert key is 99 which would be the C key.
To solve this you need the whole 16bits of the value returned from XLookupsym. Now to keep the code size down those keys that were giving the grief got sorted first. In /usr/include/X11 there is a header file called keysymdef.h that defines all possible keycodes. It was just a case of trapping those codes first before changing the key variable just to use the lower 8bits and then checking the others.
Only problem I'm having is getting those special case keys to work, Num-Lock, Pause, Caps-Lock, Print screen, etc.

Edit: Did a little test and those keys can be scanned, but looks like for some reason the enumerations in max are binding. Any idea any one?

Last edited 2012


Richard Betson(Posted 2012) [#12]
Hi dawlane,

I'll take a look at it as well tonight.

Regarding posting BRL code, this leads me to believe we can. In fact maintaining a GitHub of changes to for Linux would be possible as well.

Last edited 2012


dawlane(Posted 2012) [#13]
Regarding posting BRL code, this leads me to believe we can.

Good here's the code I've got so far. At the moment the only key I can't get to function on my keyboard is the PrtSc (Print Screen). I think this is one key that can't be successfully be extracted as I suspect the it's captured by the system first and the xev tool doesn't report it.

Rather than post a ton of code I'll just post the bits to modify.

In brl.mod/keycodes.mod/keycodes.bmx.
Change
Const KEY_ENTER=13
value to 10 or another suitable value if you want to scan this key separate from the Return key.
And at the bottom add
Const KEY_PAUSE=19
Const KEY_NUMLOCK=144
Const KEY_CAPSLOCK=20
Const KEY_SCROLL=145
Const KEY_NUMSIGN=193
Const KEY_HELP=47


Next in brl.mod/keycodes.mod/keycodes.h
replace the enum for the keys to this


Now in brl.mod/sytem.mod/system.linux.c replace the code in the function getxkey with this


Open a command terminal and change the directory to the BlitzMax bin folder and use bmk makemods to build the modules. It's not a good idea to use the MaxIDE for this as any mistake in the header file or the c file will make it crash.

A bit of test code


Last edited 2012

Last edited 2012

Last edited 2012


Richard Betson(Posted 2012) [#14]
@dawlane

Hi,

I will apply these changes here tonight. What keys does this effect?

Thanks :D


dawlane(Posted 2012) [#15]
What keys does this effect?
It depends on the keyboard local.
The code I posted will work with a full 105 key UK windows keyboard, but it shouldn't be to hard to add others.
UK

US

US-International

I've linked both window keys( left and right of the Alt keys) to KEY_LSYS and KEY_RSYS.
The context menu is linked to KEY_HELP.
The Tilde is linked to the grave sign ((`) UK and US(~)) and I've add a key for the hash sign key ((#) UK as KEY_NUMSIGN)
KEY_QUOTES is actually the apostrophe on some keyboards.
The num pad Enter key now is separate from the return key the ascii code is 10 which should be Left Line Feed.

EDIT:I've changed the code a bit so US and UK keyboard should be similar. Plus I think the code in system.liux.c may be better off being in a switch statement. As I'm sure the compiler would optimise it.

Keyboard Layout can be found here in the wikki.

getxkey code in system.linux.c as a switch/case


Last edited 2012


dawlane(Posted 2012) [#16]
Not sure but running the test code in windows looks like system.win32.c has got bugs. Keys B and N don't work or are wrong.

Last edited 2012


Richard Betson(Posted 2012) [#17]
Hi dawlane,

I have to work on a car today and tomorrow, but as soon as that's done I'll test out and apply the above code on Linux (and test on Win).

The one question I have though as far as Linux is does a 64bit OS break the key BRL key code? It's a little weird that no one has ever reported such a problem before.

The same question would apply to MaxGUI. Is the problem with MaxGUI a 64bit Linux OS only problem.?

Back on Monday. :D

Last edited 2012


Richard Betson(Posted 2012) [#18]
Be sure to see above^

But ya on BlitzMax 1.45 on Win64 several key constants just are not recognized (KEY_PAUSE,KEY_HELP,KEY_NUMSIGN,KEY_NUMLOCK,KEY_SCROLL,KEY_CAPSLOCK) plus key 'N' show as 'KEY_BACKSPACE' and 'B' just not working using your test code. This is with your changes 'not' applied, so just unmodified BRL code.

WTF.. lol. Crazy stuff. :)

Edit- You might want to post your test code in the "BlitzMax Programming" forum for others to test with. I would be interested in the results. Some may need to comment out unrecognized key constants.

Last edited 2012


dawlane(Posted 2012) [#19]
I must be getting senile in my old age.
Teach me for having too many late nights and early mornings and copying and pasting without double checking.
The B and N keys should now work as expected as I've fixed the test code.
Though certain keys are non functional in windows or wrongly mapped.

Last edited 2012


dawlane(Posted 2012) [#20]
The one question I have though as far as Linux is does a 64bit OS break the key BRL key code?
No it shouldn't as the BlitzMax key codes are defined in keycodes.bmx and keycodes.h (I think it is different on OSX) only if you alter those codes or add new ones will it have an effect.
The big problem as far as I can see is cross platform compatibility as what keys should be bound to what keycode as Windows returns on my keyboard VK_OEM_8(223 0xDF) for the grave key, but BlitzMax links it to VK_OEM_3 (192 0xC0) which is the US standard and then there is the System keys which are processed differently.
When you come to think of it the X Servers way is more flexible than the windows way of doing things.

From what I can see the constants defined in keycodes.bmx are directly related to the virtual key codes in Windows.

The code above will break cross platform keyboard compatibility but give you virtually full control of the keyboard on Linux. But as you have found out half the keys didn't work as you expected when using the original code in system.linux.c.

For compatibility issues take for instance the apostrophe(') key on my keyboard under windows it returns KEY_TILDE, yet if you look at the images above it should return KEY_QUOTES. The hash(# UK) returns KEY_QUOTES. With the looks of it BlitzMax does very little keymapping on windows and just check to see if any shift,control and system key is pressed.

Last edited 2012


dawlane(Posted 2012) [#21]
Missing posts.
Richard Betson (Posted 1 day ago) #21
OK, cool. As a Linux newbie I was not sure.:)

I'll be testing this out the next few days.

"Though certain keys are non functional in windows or wrongly mapped."

Yes this is true and perhaps a bug. For example KEY_PAUSE, KEY_HELP, KEY_NUMLOCK and KEY_SCROLL are listed in the doc's but are not recognized as constants. I'll be testing this out in Linux shortly .

This makes me wonder about how GetChar() might be functioning so I'm off to test that as well for Win 64bit and Linux.
skidracer (Posted 1 day ago) #22
Key codes are not char codes.

All keyboards will have the same key code for say the key in row 5 of column 2 no matter what char code it maps to.

Last edited 1 day ago
dawlane (Posted 1 day ago) #23
"This makes me wonder about how GetChar() might be functioning"
As skid says key codes are not char codes. When you use GetChar it will return the ASCII value of the symbols on the keyboard (what symbols depends on what modifyer key is being pressed). If I remember on Windows it's the TranslateMessage function that converts the virtual keycode (from a WM_KEYDOWN message) to a character (WM_CHAR message) and on X it's XLookupString that does it.
If you use the XEV command line tool in Linux and press a key it will give you a keycode and a keysym.

For example KEY_PAUSE, KEY_HELP, KEY_NUMLOCK and KEY_SCROLL
Well the last time I remember seeing a Help Key was on a pre-2007 Mac keyboard (I think it's now the fn key on the later models) and before that it was on a Commodore Amiga.
On windows KEY_NUMLOCK, KEY_PAUSE and KEY_SCROLL should work.

Last edited 1 day ago
Richard Betson (Posted 19 hours ago) #24
Key codes are not char codes

Right on.:)

"On windows KEY_NUMLOCK, KEY_PAUSE and KEY_SCROLL should work"

Well, on my Windows 7 64bit system I have to comment out these constants else I get "Compile Error Identifier "KEY_above identifier" not found" on BlitzMax 1.45 using the above test code.
dawlane (Posted 16 hours ago) #25
If you look in brl/keycodes.mod/keycodes.bmk they are there but are commented out. If you uncomment them and make sure that they are defined in the enum of the keycodes.h (like in the code above) then they should work.




Richard Betson(Posted 2013) [#22]
Hi,

I have not forgot about this. :) I've just been really busy and should be applying changes shortly.