FS-UAE General Feedback, Requests and Suggestions

[FrodeSolheim]

Originally Posted by Psicopatico

Done. New logfile is attached.

Looks like the emulator doesn't get a single time a "DOWN" key event from SDL.
Even more, every expected "DOWN" gets mis-matched as a "KP_ENTER" (numeric keypad enter).

Yes, the log file was very revealing. Short (well, at least not *that* long) story:
- 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:

    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;

It should be noted that the assumption in FS-UAE that most people on Linux have these scancodes for cursor keys may not be valid, I just hoped it was . But still, do you have a non-standard keyboard, or otherwise a non-standard X keyboard setup?

[Foul]

Originally Posted by FrodeSolheim

Do you know which version it last worked in? It would be useful to know which version broke it, and also if you could verify that is still works in the "old version", while it does not work in "old version + 1". In addition, the log file is always useful...

Don't know for the moment .. will do some test to find which version is working well

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 ]

Originally Posted by FrodeSolheim

...

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:

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)

[EDIT]My system is set up with a software for the management of the multimedia keys called "keytouch", but since it bases its operation on the already translated codes, that should be irrilevant.
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.

[FrodeSolheim]

Originally Posted by Psicopatico

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. (...) 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.

Well, it isn't like keyboard brands/model generally use different scancodes, these are standardized, of course, for instance as "standard 105 key PC keyboard". And you are the first to report the problem, while FS-UAE has been downloaded by users from many countries

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.

[FrodeSolheim]

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.

[FrodeSolheim]

Originally Posted by Psicopatico

(...)

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.

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.

[FrodeSolheim]

Originally Posted by Psicopatico

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.

I don't think swapping keyboards will help. What you instead should do is to try to use the evdev driver (if there is no other reason not to). I suspect you have a custom Xorg configuration file with explicit keyboard setup. Usually this is not necessary, since input devices are mostly autodetected nowadays. I recommend trying to remove keyboard config options from /etx/X11/xorg.conf. This may allow Xorg to load the evdev driver instead (this is normally the default on modern systems).

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.

Originally Posted by Psicopatico

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.

Oh, and I fully agree with the .log extension, but I don't have the means to change this. Something for global moderators, perhaps?

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.

[Foul]

any idea for my problem ?

[FrodeSolheim]

Originally Posted by Foul

i'm using a Sd Card (my Real A1200 3.9 OS system) and i'm using it with fs-uae regularly with an usb card-reader.

No problem ..BUT ! [...] i can't write on the first partition , chmod is 777, others partition ok, but not first !!! don't know why.

My system: HD0 : WB 3.9, HD1 : UTILS, HD2 : JEUX, HD3 : DEMOS

Everything PFS3 (060 direct scsi version) formated. it happend with the real SdCard and with an .HDF file of this system.

video : launching fs-uae, copying drawer in Workbench, quit/re-launch ... Drawer missing !
[ Show youtube player ]

As I understand you, you can write on the first partition, but the changes are not persistent? Please try with the most recent development version and post the log file, in case there is something interesting there.

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.

[Foul]

it's working "normaly" with WinUAE. Here is the logs from 1.3.9 version

[FrodeSolheim]

Originally Posted by Foul

it's working "normaly" with WinUAE. Here is the logs from 1.3.9 version

Well, there is at least one suspicious line in there (the size):

Mounting uaehf.device 0 (0) (size=18446744072518336512):

Could you boot the same system in WinUAE with logging enabled (misc panel, I think), and post the both the WinUAE bootlog and log file? I will use this to check if there are other mismatching logging statements will can reveal more about the problem.

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).

[Foul]

Kubuntu 12.04 64bits, yes and here is the WinUAE logs )

(can't test 32 bits version...)

[Toni Wilen]

Originally Posted by Foul

Everything PFS3 (060 direct scsi version) formated.

Logs says second partition is SFS. Other partitions are PDS3. (=PFS3DS)

[Foul]

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

[Foul]

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 ... :\

[FrodeSolheim]

Originally Posted by Foul

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

Thanks for the test file The problem should hopefully be fixed for you in the newly released version 1.3.10 (it works here, now).

Originally Posted by Foul

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 ... :\

A bit more information here, please! -Do you mean that pressing (Left or right) Amiga key + another key generally does not work? Does it never work, or does it only not work when using KME? What about shortcuts in other Amiga programs - Similar problems there?

[Foul]

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

[FrodeSolheim]

Originally Posted by Foul

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

The shortcuts are case sensitive, try using:
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