Open synaptis opened 4 years ago
Same issue here, found on Debian: https://github.com/MichaIng/DietPi/issues/3022 I'll check and compare the logs to verify that it is the same underlying issue, however symptoms and workaround (RDP over VNC) match.
I'm facing the same issue, xorg appers to ignore the inputdevices for some reason, they are not listed in the (sesman)log output for the serverlayout and for some reason default values are then used which break mouse & keyboard - I've tried to mess with the config file, but nothing I do gets xorg to use the damn xrdpkeyb & xrdpmouse devices:
[ 8285.543] Build Date: 04 September 2020 01:34:27PM
[ 8285.543] xorg-server 2:1.20.8-2ubuntu2.4 (For technical support please see http://www.ubuntu.com/support)
[ 8285.543] Current version of pixman: 0.38.4
[ 8285.543] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 8285.543] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 8285.543] (++) Log file: ".xorgxrdp.10.log", Time: Fri Oct 16 19:54:56 2020
[ 8285.543] (++) Using config file: "/etc/X11/xrdp/xorg.conf"
[ 8285.544] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 8285.544] (==) ServerLayout "layout"
[ 8285.544] (**) |-->Screen "Screen (xrdpdev)" (0)
[ 8285.544] (**) | |-->Monitor "Monitor"
[ 8285.544] (**) | |-->Device "Video Card (xrdpdev)"
[ 8285.544] (**) Option "DontVTSwitch" "on"
[ 8285.544] (**) Option "AutoAddDevices" "off"
[ 8285.544] (**) Not automatically adding devices
[ 8285.544] (==) Automatically enabling devices
[ 8285.544] (==) Automatically adding GPU devices
[ 8285.544] (==) Automatically binding GPU devices
[ 8285.544] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 8285.544] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 8285.544] Entry deleted from font path.
[ 8285.544] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 8285.544] Entry deleted from font path.
[ 8285.544] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 8285.544] Entry deleted from font path.
[ 8285.544] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 8285.544] Entry deleted from font path.
[ 8285.544] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 8285.544] Entry deleted from font path.
[ 8285.544] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[ 8285.544] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 8285.544] (==) |-->Input Device "<default pointer>"
[ 8285.544] (==) |-->Input Device "<default keyboard>"
[ 8285.544] (==) The core pointer device wasn't specified explicitly in the layout.
Using the default mouse configuration.
[ 8285.544] (==) The core keyboard device wasn't specified explicitly in the layout.
Using the default keyboard configuration.
-- snip snip 8< --
[ 8285.608] (II) Using input driver 'mouse' for '<default pointer>'
[ 8285.608] Option "CorePointer" "on"
[ 8285.608] Option "driver" "mouse"
[ 8285.608] Option "identifier" "<default pointer>"
[ 8285.608] (**) Option "CorePointer" "on"
[ 8285.608] (**) <default pointer>: always reports core events
[ 8285.608] (WW) <default pointer>: No Device specified, looking for one...
[ 8285.608] (EE) <default pointer>: Cannot find which device to use.
[ 8285.608] (==) <default pointer>: Protocol: "Auto"
[ 8285.608] (**) Option "CorePointer" "on"
[ 8285.608] (**) <default pointer>: always reports core events
[ 8285.608] (EE) xf86OpenSerial: No Device specified.
[ 8285.608] (EE) <default pointer>: cannot open input device
[ 8285.608] (EE) PreInit returned 2 for "<default pointer>"
[ 8285.608] (II) UnloadModule: "mouse"
[ 8285.608] (II) Using input driver 'kbd' for '<default keyboard>'
[ 8285.608] Option "CoreKeyboard" "on"
[ 8285.608] Option "driver" "kbd"
[ 8285.608] Option "identifier" "<default keyboard>"
[ 8285.608] (**) Option "CoreKeyboard" "on"
[ 8285.608] (**) <default keyboard>: always reports core events
[ 8285.608] (**) Option "CoreKeyboard" "on"
[ 8285.608] (**) <default keyboard>: always reports core events
[ 8285.608] (**) Option "Protocol" "standard"
[ 8285.609] (EE) kbd: <default keyboard>: failed to set us as foreground pgrp (Bad file descriptor)
The fix for me was to add Option "CoreKeyboard" and Option "CorePointer" to the inputdevices in /etc/X11/xrdp/xorg.conf since the inputdevices in the serverlayout section are apparently ignored so no core pointer and keyboard exists, which leads to forced default devices. No idea why this is suddenly the case, it worked fine on ubuntu 18.04, but broke for me in 20.04.
Section "InputDevice"
Identifier "xrdpKeyboard"
Driver "xrdpkeyb"
Option "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "xrdpMouse"
Driver "xrdpmouse"
Option "CorePointer"
EndSection
Many thanks for sharing this, I'll test it on Debian where this was broken since at least Stretch, I think even Jessie already.
Accompnying xorg bug report: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1086
I have been troubleshooting an issue where I had no keyboard/mouse using xrdp on a recent Debian install. Adding "CorePointer" and "CoreKeyboard" worked for me. Thanks for sharing -- I would never have found that on my own.
I have no idea what changed, there was no xrdp or xorgxrdp package upgrade recently, but suddenly on Debian Stretch (with backports packages), Buster and Bullseye keyboard and mouse input works OOTB without the options being present in the config file. Also no xorg package upgrade was done recently, especially not on Debian Stretch 🤔.
@esoren
Are you on Debian Buster, which desktop do you use and if you are in mood, mind you retesting it without the settings after an apt update; apt upgrade
? I'm not sure whether I should still add the setting to our implementation, to be failsafe, or can trust in my tests.
EDIT: Okay, tested a few more devices and on one notebook (as XRDP server) the broken input was present and adding the two options fixed it. Would be interesting what the underlying reason is, however since there are no downsides the fix seems to be a reasonable to assure it works. If someone wants to script it:
grep -q 'Option "CoreKeyboard"' /etc/X11/xrdp/xorg.conf || sed -i '/^[[:blank:]]*Driver "xrdpkeyb"/a\ Option "CoreKeyboard"' /etc/X11/xrdp/xorg.conf
grep -q 'Option "CorePointer"' /etc/X11/xrdp/xorg.conf || sed -i '/^[[:blank:]]*Driver "xrdpmouse"/a\ Option "CorePointer"' /etc/X11/xrdp/xorg.conf
Just confirming that this fixed problem with a newly install Debian 10 installation. Could login, but no mouse or keyboard working. Though first it was read-only mode, but found this open issue and then got it fixed by adding needed thing to xorg.conf
@MichaIng , @mudnaes , @esoren - this may now be fixed in devel - see #181 and neutrinolabs/xrdp#1784.
I notice in this post above by @Hoernchen that:-
[ 8285.544] (==) ServerLayout "layout"
[ 8285.544] (**) |-->Screen "Screen (xrdpdev)" (0)
which seems consistent with #181 - the ServerLayout should be X11 Server
, not layout
.
Apologies for missing this one first time round.
Great, thanks for shipping a fix. Yes that all makes sense with the skipped ServerLayout when being defined in override configs. Since the InputDevice were picked up in any case, defining the options there worked as well, but your solution looks cleaner to me. Probably it can be merged as patch into major distributions, like Debian Buster (not sure if Bullseye will get the next version still merged)?
It could be merged, but I think this is unlikely to happen. The Debian/Ubuntu packages are fixed at a particular version, and although they will take security fixes, that's about it. Other launchpad faults I've raised have gone nowhere (see e.g. https://bugs.launchpad.net/ubuntu/+source/xrdp/+bug/1911435). That's a decision they've made on their side, and there's nothing we can do here to affect that. Fedora/CentOS take pretty much anything we care to raise with them.
Indeed, I experience the same. I think it's something to convince the package maintainer(s) from first to give it more voice inside the Debian community. There are other examples were much larger patches have been merged into stable Debian packages, which were not in particular security related.
The other thing here is that there is not even a related bug report on the Debian bug tracker, I guess since it's mostly an issue that SBC users face, where distros like Raspberry Pi OS, Armbian or us (DietPi) either by default or via config tool allow to disable screen blanking, as such devices are often used in combination with LCDs with a monitoring or kiosk mode app running.
Since Debian Bullseye will be released this summer, is probably better to concentrate on this. I'll raise a request to have it merged there, in case the upstream xorgxrdp release will be too close to Bullseye release.
It's a good point about the Debian bug tracker. We don't normally push things downstream from here unless they're distro-specific, like the one I've linked above, and we've specifically identified them.
The next release of xrdp/xorgxrdp will probably be end of April. Since Bullseye appears to be in soft freeze at the moment, I think it's unlikely they'll be taking that one. If you're happy to raise a request on Debian, that would be very helpful. Feel free to post a link here if you do.
Many thanks
I opened a merge request at the Debian Gitlab platform. Not sure if it's the most productive way and if the formalities are correct, but I'll give it a week before supporting it with a bug report: https://salsa.debian.org/debian-remote-team/xorgxrdp/-/merge_requests/1
Usually, Debian only accepts security updates but I believe they also accept fatal bug fixes. For example, the daemon process crashes or it doesn't work at all. Personally, I think no keyboard or mouse implies "it doesn't work at all".
Thanks @MichaIng - hopefully you'll have more luck than I've had!
I think no keyboard or mouse implies "it doesn't work at all".
That is my hope as well, even that only systems are effected with such an xorg.conf override. Let's see.
I am having a similar problem.. and as crazy as it may sound I want to have 2 keyboard devices connected to the same computer and use one of them with an xrdp session. I seem to get a lot of Closed socket 19's though..
My wrapper file already has this in it as well/
allowed_users=anybody
May 27 19:06:30 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)
May 27 19:08:37 RRZ87MX xrdp[134083]: message repeated 36 times: [ (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)]
May 27 19:08:40 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)
May 27 19:08:58 RRZ87MX xrdp[134083]: message repeated 5 times: [ (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)]
May 27 19:09:01 RRZ87MX PackageKit: daemon quit
May 27 19:09:01 RRZ87MX systemd[1]: packagekit.service: Succeeded.
May 27 19:09:01 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)
May 27 19:09:47 RRZ87MX xrdp[134083]: message repeated 13 times: [ (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)]
May 27 19:09:50 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] xrdp_wm_log_msg: connection problem, giving up
May 27 19:09:50 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] Closed socket 19 (AF_UNIX)
May 27 19:09:50 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] xrdp_wm_log_msg: some problem
May 27 19:09:50 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] xrdp_mm_module_cleanup
May 27 19:09:50 RRZ87MX xrdp[134083]: (134083)(140002481489728)[DEBUG] Closed socket 18 (AF_INET6 ::1 port 42018)
Did you read and try it with the fix provided above? Open your /etc/X11/xrdp/xorg.conf
and add these lines (or Option "DefaultServerLayout" "X11 Server"
only to the correct position): https://github.com/neutrinolabs/xorgxrdp/pull/181/files
I found this thread by random googling. I ran into the same problem but independent of xorgxrdp. I think there is something messed up with input-related stuff and evdev or something like that. I don't recall these issues ~2 years ago, but nowadays I can not get my keyboard and mouse to work anymore after compiling xorg-server from source. "startx" works fine, but the mouse and keyboard does not work. Prior to that I could resolve this by compiling all evdev and libinput related parts, but this no longer works either, and I don't get a lot of useful info from xorg-server either. :(
Perhaps it is time to look whether wayland solves these issues ...
Just a hint for everyone who applied this patch manually and then did or plans to do a distribution upgrade form Debian Buster to Bullseye or similar: Newer xorgxrdp
requires to load an additional module for glamor support, if the compile was set at least, which is done on Debian Bullseye. Since changing a configuration file manually leads to APT/dpkg not upgrading it without user confirmation, assure that you do the upgrade an re-apply the input fix patch if not shipped by the new distribution package config yet, e.g.:
mv /etc/X11/xrdp/xorg.conf.dpkg-dist /etc/X11/xrdp/xorg.conf
grep -q 'DefaultServerLayout' /etc/X11/xrdp/xorg.conf || sed -i '/Section "ServerFlags"/a\ Option "DefaultServerLayout" "X11 Server"' /etc/X11/xrdp/xorg.conf
systemctl restart xrdp
I seem to be facing the same issue after updating from Ubuntu 18.04 to Ubuntu 20.04. My mouse and keyboard are not working on the login screen. I have tried the fix described here and altered my /etc/X11/xrdp/xorg.conf
, without success.
I am not very savvy to know which different log and configuration files I should look at, however, when I run sudo systemctl status xrdp
I do get a warning about a keympa file that doesn't match.
Dez 16 21:28:41 flu xrdp[17665]: (17665)(140012020717376)[INFO ] Loading keymap file /etc/xrdp/km-00000807.ini Dez 16 21:28:41 flu xrdp[17665]: (17665)(140012020717376)[WARN ] local keymap file for 0x00000807 found and doesn't match built in keymap, using local keymap file
Does anyone have any more pointers?
Are there any files in /etc/X11/xorg.conf.d
in your case? Else it may be a different issue.
Thanks for your reply @MichaIng No, this directory does not exist.
Then I guess your issue is a different one and a newly opened issue would be better to investigate it. This one here was caused by mentioned files overriding the XDRP X11 config partly, and was solved.
thanks @MichaIng. I do highly appreciate your response. I will open another ticket once I get a chance to look into it again so as to gather some more information.
I have the same problem in freebsd, but is seems to be related to when i have 2 mice connected. I'm not totally sure but it is something you can investigate.
Background and workarounds for the original issue are explained throughout this thread. Same as in flurin-conradin's case: If you do not have any override config in /etc/X11/xorg.conf.d
, your issue is unrelated to this thread and I suggest to open a new one.
Client: Windows 10 build 19541.1000 Server: Fedora 30 Workstation
Package versions: xorgxrdp-0.2.13-1.fc30.x86_64 xrdp-selinux-0.9.13-1.fc30.x86_64 xrdp-0.9.13-1.fc30.x86_64
Issue: When connecting to the Fedora 30 machine via mstsc and xorg the connection and login are successful, the desktop displays and updates (MS Teams opens by default and I can see it update) but the mouse and keyboard inputs are not registered. I have left a connection in this state for 5 minutes and without the issue resolving. Eventually I have to close the mstsc client.
I have tried this with both my laptop keyboard and trackpad and separate USB connected keyboard and mouse. Also tried lowering the quality/bandwidth in the mstsc settings.
Connections with the same configuration over xvnc do not show this issue. Xorg is preferred as it recognises my monitors as separate screens rather than a single spanned screen.
/var/log/xrdp-sesman.log:
/var/log/xrdp.log:
J
/etc/xrdp/startwm.sh:
/etc/xorg/xorg.ini:
jounnalctl :