[hatari-devel] Caps Lock bug in maxYMiser
Eero Tamminen
eerot at users.berlios.de
Sun Mar 21 15:19:18 CET 2010
Hi,
On Sunday 21 March 2010, Anders Eriksson wrote:
> On Sun, 21 Mar 2010, Eero Tamminen wrote:
> >> Undefined symbols:
> >> "_Resolution_Search", referenced from:
> >> _HostScreen_setWindowSize in libFalcon.a(hostscreen.o)
> >> "_Resolution_GetLimits", referenced from:
> >> _Screen_SetResolution in screen.o
> >> _HostScreen_setWindowSize in libFalcon.a(hostscreen.o)
> >> ld: symbol(s) not found
> >> collect2: ld returned 1 exit status
> >
> > Were you using CMake generated Makefiles? Just re-running cmake
> > should fix that I think.
>
> Oh I was not aware that one had to create new Makefiles between HG
> updates, indeed after doing that it compiled.
The normal Makefiles automatically "notice" when new files are added.
CMake generated Makefiles don't seem to have a rule for that, but I guess
Thomas could add something for it. Thomas?
> However, the CapsLock key bug is still there after commenting out
> else if (symkey == SDLK_CAPSLOCK)
> {
> /* Simulate another capslock key press */
> IKBD_PressSTKey(0x3A, true);
> }
>
> And the bug is also in Windows as XiA have the same problem. Maybe I'll
> install Ubuntu in a virtual machine and see if it works there.
I just noticed this in the SDL release notes:
http://www.libsdl.org/release/changes-1.2.html
You need to use SDL_DISABLE_LOCK_KEYS environment variable to enable
normal up/down events for Caps-Lock and Num-Lock keys.
Support for that was added in SDL v1.2.14 released last October.
If it works fine for you, I guess we could enable it in Hatari too if you
tell what value we should use for it (if that doesn't change things for
Linux). Setting environment variable doesn't harm anything although one
would use Hatari with a version of SDL that doesn't support some particular
variable.
- Eero
More information about the hatari-devel
mailing list