>>> 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: >>> "The procedure entry point libintl_snprintf could not be located in the >>> dynamic link library [...]\lib\libfontconfig-1.dll." Copying the >>> libintl-8.dll in lib one level up works. >> That's odd, I've tested a few builds on a clean VM and I didn't see this >> error. Is this an alert box? Which shortcut do you run? > > Yes, I uploaded screenshots to https://imgur.com/a/eD4NltE . The left > dialog appears first and the right one immediately afterward. > > There are several other copies of libintl-8.dll on my system, since a > lot of open source software ships it. One of those might be getting > picked up from PATH instead of the one in lib. Xpra.exe, > Xpra-Launcher.exe and Xpra_cmd.exe all fail. Yes, that must be it. That's a relief: I have verified and the ZIP file you are having problems with does work fine on a clean system.
> After copying the dll from > lib one level up, everything works. Rather than moving the DLLs, I've changed the path search order: http://xpra.org/trac/changeset/26483 This should fix the problem on your system. There's a 4.1 beta build here: https://xpra.org/beta/windows/ >>> 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. >>> This is not very useful as generally X11 keycode = PC/AT scancode + 8. >>> Client should probably add 8 to the scancode (event.keycode) when >>> connecting from Win32 to X11. >> This is not enabled by default and it is not meant to be used across >> operating systems. >> This is only useful at present when the client and server OS are >> identical. (ie: Linux to Linux, or Windows to Windows) >> When a translation is going to be needed, don't use raw mode. > > Is there any other way to _not_ have Xpra do keysym-based mapping though? Whenever this approach has been attempted, there has always been problems. I've just tried it again with an MS Windows client connecting to a Linux seamless server, and it didn't go well. > Use case: I use a heavily customized multilingual layout on Windows. > When connecting to X11 boxen, I generally only need standard US layout. > I would prefer that keys are mapped using the server-side Xkb layout > starting from keycodes (as happens with VNC, NoMachine and such) to > avoid funkiness. > > Example of a problem: the [ key (scancode 0x1a) produces ä (adiaeresis) > with my Windows layout. When I connect with Xpra, it sets Xkb layout > "us" on the remote (my Windows layout has locale US so this is an > acceptable guess). When I press the [ key, nothing happens because (as > far as I can tell) Xpra server side doesn't know what to do with the > keysym adiaeresis since it doesn't appear in the Xkb us layout. What > would preferably happen is that the scancode/keycode gets passed to X as > usual and eventually pops up as [. You can try this server-side change (without --keyboard-raw): http://xpra.org/trac/changeset/26486 It will use the keyval for any key that it fails to locate. This should do what you want. If not, please create a ticket with more details. Cheers, Antoine > > -Valtteri _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users
