25 May 2012, 21:18 | #81 | |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
- FS-UAE uses "scancodes" instead of keysyms to allow for positional mapping independent of chosen keyboard layout ("Scancodes" do not necessarily correspond to actual keyboard scancodes, but are called scancodes in the SDL api) - Your keyboard does not generate the "scancodes" FS-UAE expects. - Down is mapped to FS_ML_KEY_KP_ENTER because your down key has scancode 104 but FS-UAE expects 104 to be KP_Enter.. - Left, Up and Right accidentally works because the "scancodes" does not match anything FS-UAE expects, and in this case, keysym value reported by SDL is used as the key code (and SDLK_UP has the same value has FS_ML_KEY_UP, etc). In earlier versions, when FS-UAE used keysyms (translated key codes) and not scancodes, the cursor keys would work properly for you. But the reason for using scancodes was to get the emulated Amiga working properly with international keys and workbench keymaps etc. These are the scancodes FS-UAE expects for cursor keys on Linux: Code:
g_key_map[111] = FS_ML_KEY_UP; g_key_map[113] = FS_ML_KEY_LEFT; g_key_map[116] = FS_ML_KEY_DOWN; g_key_map[114] = FS_ML_KEY_RIGHT; Last edited by FrodeSolheim; 26 May 2012 at 00:46. |
|
25 May 2012, 21:21 | #82 | |
Registered User
|
Quote:
fs-uae_1.1.0-0_amd64.deb not working .. can't use older .. 1.0.0 refuse to boot... i think it never worked in fact :\ video : launching fs-uae, copying drawer in Workbench, quit/re-launch ... Drawer missing ! [ Show youtube player ] Last edited by Foul; 25 May 2012 at 22:21. |
|
25 May 2012, 22:20 | #83 |
Posts: n/a
|
Humm, I think I get it.
FS_UAE gets its input from codes directly generated by the keyboard and not from the ones translated by the kernel. Fact is, different keyboards *may* generate different codes, and in fact it is. I think that's the reason why a kernel translation system exists in the first place. My keyboards is a Logitech EX 110. It is a wireless keyboard with multimedia keys and mouse combo, but the receiver is attached to the case via the "usual" two PS2 connectors. In fact it is recognized as a "standard" AT keyboard with an Intel 8042 controller, as the wireless communication is trasparent to the system. Following is the relevant parts of the "lshal" command: Code:
udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' info.addons.singleton = {'hald-addon-input'} (string list) info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) info.product = 'AT Translated Set 2 keyboard' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' (string) input.device = '/dev/input/event0' (string) input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) input.product = 'AT Translated Set 2 keyboard' (string) input.x11_driver = 'evdev' (string) linux.device_file = '/dev/input/event0' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/devices/platform/i8042/serio0/input/input0/event0' (string) Other than this, no other fancy setup is in place. On the contrary, the system is pretty much as default stock. [/edit] So, if FS_UAE uses directly scancodes for a legitimate operational reason, can't we route around the problem by making menu items click-able, in addition to the navigation by keyboard? At present, mouse-clicking on any area of FS-UAE - menu buttons included - gives the focus to the emulated system. My quess is there may soon appear other cases of users with different keyboards brands/model which supply even different codes, so tryng to - say - put up a table of exceptions may quickly become a mess. Last edited by Psicopatico; 25 May 2012 at 22:29. |
25 May 2012, 22:59 | #84 | |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
To give an example why translated keysyms are not used: Compared to Norwegian and English keyboards German keyboards have Z and Y swapped. That is, the virtual keycodes are swapped when pressing the keys. The physical key Z/English - Y/German has the same scancode. So the Z/Y swap is caused by different keymaps, not different physical keyboards. Anyway, to make the Z/Y keys work correctly for Amiga emulation, the physical Z (English) key is mapped to the corresponding Amiga key. That is, by pressing Z (English keyboard), this will result in "Z" in workbench if using English workbench keymap, and "Y if using German workbench keymap. Similarly, by pressing Y (German keyboard), this will result in "Z" in workbench if using English workbench keymap, and "Y if using German workbench keymap. If I simply had used translated key codes ("keysyms") instead, this would not work properly. I do not know of any better / more robust way to solve the key mapping problem without user intervention: But here are some alternatives (not all are good ideas ): - use keysyms instead of keycodes and require that everyone switch to (for instance) English keyboard layouts when using FS-UAE (not an alternative). - use keysyms and require that user configures keyboard layout in the config file (and FS-UAE has information about all different keymaps, and what physical key the key codes correspond to) - alternatively try to get this information automatically from the system in some cases, where it may be possible (would be a nightmare). - allow the user to create a config file mapping keycodes manually, when the default key mapping does not work properly. - implement an option to disable keycode mapping, and use translated keysyms as provided by SDL. This would actually work quite well in most cases, and would definitely solve your cursor key problem (but international keys would probably not work correctly in the emulated Amiga). A combination of the last two points are probably the best way to make FS-UAE more flexible when it comes to keycodes/scancodes. Last edited by FrodeSolheim; 26 May 2012 at 12:18. |
|
25 May 2012, 23:17 | #85 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
I should also clarify that the "scancodes" SDL provides (which is provided by X on Linux) is not the same as the scancodes the keyboard actually sends, which are sequences of bytes, and not a single (low) number. And additionally, the same key on the same keyboard on the same computer, gives a different "scancode" in for instance Ubuntu and in Windows. So, the "scancode" is already translated somehow by the system -but keymaps -national key mappings- are not taken into consideration yet. So, the term "scancode" is not really correct in this case, for Linux, "X keycode" is probably a better term, though it is called scancode in the SDL api.
Last edited by FrodeSolheim; 26 May 2012 at 00:53. |
26 May 2012, 00:41 | #86 |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
The problem may be related to use of evdev vs kbd driver in X. Could you post the log file /var/log/Xorg.0.log, so I can check if this can be the case?
It seems different X keycodes (SDL "scancodes") are used for cursor keys depending on whether X uses evdev or kdb. For instance, see https://bugzilla.redhat.com/show_bug.cgi?id=471000 for a similar problem, up key is either 111 or 98 -same as in your case. FS-UAE expects up arrow key to be 111 but on your system it is keycode 98. Last edited by FrodeSolheim; 26 May 2012 at 00:57. |
26 May 2012, 11:17 | #87 |
Posts: n/a
|
Hi. Xorg log is attached.
It loads the "kbd" module and not the "evdev" one. I'm getting lost on all of this, since I'm no expert on this stuff either. I guess I'm going to try each of a couple spare keyboards I have, a wired NMB Cypress and... wait for it... a shiny IBM Model M from 1994! Yes, that one ! This just to see if something different happens. Slightly Off-Topic: I see the attachment manager rejects files with the ".log" extension. That's no big deal, it's easy enough to copy 'em adding ".txt". Can you please add a relevant row in the attachment key table? That would eliminate the nuisance. Thanks in advance. |
26 May 2012, 11:34 | #88 | ||
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
I suspect that you with your current setup also will have problems with arrow keys in Virtualbox, VMWare and possibly remote desktop viewers. With evdev, the keycodes should change and allow FS-UAE (and other applications with similar needs) to work. It should not affect normal applications in a negative way, since applications normally use translated keysyms, which will be correct also with evdev. Quote:
Last edited by FrodeSolheim; 26 May 2012 at 11:56. |
||
26 May 2012, 12:08 | #89 |
Posts: n/a
|
You were right: starting Xorg with the "evdev" module loaded instead of "kbd" made FS-UAE menu keys working as expected ("new" xorg log is attached for reference).
But mind you, the xorg.conf was entirely set up at install time by the install tool (YaST, in my case as this is an OpenSUSE system), no custom intervention happened by me. Well, except for the video section, as in that case I *do* have a non standard dual-monitor set-up. By the way, using "evdev" screwed the extra multimedia key bindings I previously had (browser, volume, play/stop/pause, various software and the such), but i guess I just have to fiddle a bit with the configurator for keytouch, as it has the choice of various input sources. |
26 May 2012, 13:51 | #90 |
Registered User
|
any idea for my problem ?
|
27 May 2012, 12:48 | #91 | |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
Some useful tests you can do is to try the .hdf file with other UAE variants, (and especially the latest WinUAE release if you can run that) and let me know if it works properly in those. |
|
27 May 2012, 12:55 | #92 |
Registered User
|
it's working "normaly" with WinUAE. Here is the logs from 1.3.9 version
|
27 May 2012, 13:21 | #93 | |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
Code:
Mounting uaehf.device 0 (0) (size=18446744072518336512): Also, are you using the 64-bit version of FS-UAE? If so, is the same bug present with the 32-bit version? (But please prioritize the WinUAE log files first). |
|
27 May 2012, 13:43 | #94 |
Registered User
|
Kubuntu 12.04 64bits, yes and here is the WinUAE logs )
(can't test 32 bits version...) |
27 May 2012, 16:39 | #95 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,567
|
|
27 May 2012, 17:50 | #96 |
Registered User
|
yep ! don't now why .. everything was pfs3 formated.. will change it later.. but don't explain my probs
@Frode, i'm uploading requested file but it's lonnnggg |
27 May 2012, 21:08 | #97 |
Registered User
|
Another thing : I'm learning assembler and i'm using asm-one/pro
When i want to assemble/edit/debug .. the short key are Amiga + A Amiga + E Amiga + D (just an example...) and it's not working. I'm using KME to remap key, Amiga key alone is working, E/A/D are working but not both ... :\ |
28 May 2012, 17:50 | #98 | ||
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
Quote:
Last edited by prowler; 28 May 2012 at 23:26. Reason: Fixed new version number. |
||
28 May 2012, 22:31 | #99 |
Registered User
|
seem to append only in Asm-one/pro ... all keys are working under workbench ... and Cygnused for example... but here i can't use Shortcuts
edit : you can try on my system now |
29 May 2012, 00:47 | #100 | |
FS-UAE Developer
Join Date: Dec 2011
Location: Førde, Norway
Age: 43
Posts: 4,043
|
Quote:
Right Super + Shift + E (Right Amiga + Shift + E), etc A bit off-topic: I was suprised to learn that you French people use shift to type numbers... I initially thought you just had gone mad and created an insane keymap |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FS-UAE Stable Series - Questions, Feedback and Bug Reports | FrodeSolheim | support.FS-UAE | 253 | 18 July 2023 02:33 |
Amiga Lore Feedback and Feature Requests | CodyJarrett | project.Amiga Lore | 16 | 05 July 2019 11:55 |
Perfect General | mai | support.Games | 17 | 04 June 2009 22:21 |
General Discussion | Zetr0 | project.Amiga Game Factory | 12 | 15 December 2005 13:53 |
|
|