I am not sure if this answers your question. You can use x11/xev to see which key generates which output. With x11/xmodmap and x11/xkbset you can change the assignment and tweak the behaviour.
Why would you even want to do that, and why do you expect any different outcome when two things are competing for the same resource?It's again related to me trying to force X the run on predefined VTs. I did a lot of testing during the last days and it seems the reason for the unresponsive keyboard when starting X on a VT also used by getty is a conflict on reading from the underlying device ...
Note that the X server usually requires a virtual terminal for display
purposes, so at least one terminal must be left unused by getty(8) so
that it can be used by the X server.
Why would you even want to do that, and why do you expect any different outcome when two things are competing for the same resource?
From syscons(4):
Code:Note that the X server usually requires a virtual terminal for display purposes, so at least one terminal must be left unused by getty(8) so that it can be used by the X server.
sleep 9999 0<&-
which as i understand it resolves the conflict by closing the input descriptor. I just can't seem to find a way (maybe be because this really is impossible - i don't know) to do this for the terminal where startx
is executed. Combined these findings point at a workaround though. It's just a little annoying and i don't have the time to code it right now so i figured why not check if there is an easier option elsewhere (as in some potential input method i don't know about that sidesteps the issue). X -help
for some commandline options not documented in Xserver(1), in particular:-novtswitch don't automatically switch VT at reset & exit
-sharevts share VTs with another X server
vtXX use the specified VT number (1-12)
-keeptty don't detach controlling tty (for debugging only)
exec xinit [opts] -- [serveropts]
as it's last line to replace the shell process.This here looks quite similar to what you are trying to accomplish, don't you think?
tty
where i used fgconsole
and xinit
vs. startx
. As for his problems with consolekit: None of my systems run consolekit (or any *kit, logind, dbus, and so on) so i've (obviously) never had them. It's still quite interesting to see that -keeptty actually seems to have useful effects way beyond being a debug option. I am sadly quite busy right now but i will definitely give this a try once i have some open space for experimentation. *.err;kern.warning;auth.notice;mail.crit /dev/console
-file /var/log/console.log
switch. /var/log/console.log root:operator 640 5 1000 * J
# Allow members of group operator to read the system console
own console root:operator
perm console 0640
service devfs restart
. Maybe conscontrol mute on
or use it to redirect messages to another VT.The main differences being him usingtty
where i usedfgconsole
andxinit
vs.startx
.
startx
is just a somewhat more user-friendly frontend to xinit
and also a shell script by itself, so feel free to copy&paste whatever you need from startx
to a custom script. I'd say invoking xinit
via exec
alone could make a difference, and if that doesn't suffice, there's still some flags to play around with.For that exact reason I always set the first VT to not run a getty(8) in /etc/ttys, so that it just displays the console log but has no login capabilities:If you want to start X11 from the 1st VT /dev/ttyv0, keep in mind that by default in syslog.conf(5):
*.err;kern.warning;auth.notice;mail.crit /dev/console
& that might interfere.
ttyv0 "/usr/libexec/getty Pc" xterm off secure
That's dangerous: e.g. when your keyboard's ALT, CTRL and/or function keys got messed up, you can not switch the VT. Admittedly, that happens seldomly, but we all believe in Murphy's Law, right?For that exact reason I always set the first VT to not run a getty(8) in /etc/ttys, so that it just displays the console log but has no login capabilities:
ttyv0 "/usr/libexec/getty Pc" xterm off secure
I believe in IBM buckling spring keyboards, manufactured ~1988, there is no such thing as messed up keysThat's dangerous: e.g. when your keyboard's ALT, CTRL and/or function keys got messed up, you can not switch the VT. Admittedly, that happens seldomly, but we all believe in Murphy's Law, right?
You might want to check outX -help
for some commandline options not documented in Xserver(1), in particular:
Also consider writing a custom startup script that usesCode:-novtswitch don't automatically switch VT at reset & exit -sharevts share VTs with another X server vtXX use the specified VT number (1-12) -keeptty don't detach controlling tty (for debugging only)
exec xinit [opts] -- [serveropts]
as it's last line to replace the shell process.
-keeptty
has been disappointed. The behavior stays the same (keyboard input results in 1 core spiking to 100% and nothing happening). I've noticed some other details though. As i had already mentioned before X happily uses VTs where a shell is running as long as something like sleep 9999 0<&-
is currently executed there. Concerning this i made the following observations: sleep
is running in the shell that is occupying the target VT the characteristic CPU spike that happens with targeting the terminal where startx
is being excuted doesn't happen and X is not fully unresponsive to keyboard input (it will eventually recognize a keypress but miss the keyup resulting in the key "hanging" and being repeated indefinitely). sleep 9999
with no redirection at all is enough to make X work on the target VT. xinit
does not seem to make any noticeable difference to using startx
. startx
/ xinit
becomes a direct child of login
(i might still try to replace login and thereby making it become a child to init
but i somewhat doubt that to make a huge difference). sleep 9999
but it won't help. Something is clearly special about launching X to run on the current VT but i can't figure out what it is. sleep 9999
while targeting the VT where X was started from breaks. As i said above i will likely try to also replace the login process but i don't see any logic why that could help eliminating whatever breaks the keyboard input. startx
/ xinit
on an unused VT which (while kinda ugly) would according to my observations up to this point likely work around the problem. I am still puzzled as to why this issue exists in the first place and i am also quite sure there would be a cleaner solution but for now i just want to have this working so i can move on with setting up my desktop. I will update this topic when i have settled with something.Doesn't X11 use the 1st unused VT by default?
vtX
switch.Maybe additionally there's a minimum VT number hardcoded somewhere (e.g. in the display manager).
sleep 9999
). To archive this it just can't be started from VT1. The same happens for all the other VTs. For some bizarre reason starting X on a random VT works even if a shell is running there as long as it isn't actively waiting for input. One would think that to be the case for the shell that executes startx
/ initx
pretty much automatically but in reality it obviously isn't.Have you played around with kern.evdev.rcpt_mask already? The switch to evdev/libinput unfortunately left more than just a few broken eggs in it's path. Although most issues seem to have been ironed out now. As keyboard input seems to be the culprit, it's also thinkable that kbdmux(4) has something to do with it. By default kern.evdev.rcpt_mask is set up to use kbdmux(4) and sysmouse(4). You could try setting kern.evdev.rcpt_mask to a value of 12 (0x0C) in /etc/sysctl.conf to use hardware keyboard and hardware mouse instead, to see if it makes any difference in regards to the problem.I don't think so. I am not even using a display manager and starting X on VT1 works perfectly fine (if the appropriate precautions are taken - i.e.sleep 9999
). To archive this it just can't be started from VT1. The same happens for all the other VTs. For some bizarre reason starting X on a random VT works even if a shell is running there as long as it isn't actively waiting for input. One would think that to be the case for the shell that executesstartx
/initx
pretty much automatically but in reality it obviously isn't.
/*
* Keyboard and mouse events recipient mask.
* evdev_rcpt_mask variable should be respected by keyboard and mouse drivers
* that are able to send events through both evdev and sysmouse/kbdmux
* interfaces so user can choose prefered one to not receive one event twice.
*/
#define EVDEV_RCPT_SYSMOUSE (1<<0)
#define EVDEV_RCPT_KBDMUX (1<<1)
#define EVDEV_RCPT_HW_MOUSE (1<<2)
#define EVDEV_RCPT_HW_KBD (1<<3)
extern int evdev_rcpt_mask;
Have you played around with kern.evdev.rcpt_mask already? The switch to evdev/libinput unfortunately left more than just a few broken eggs in it's path. Although most issues seem to have been ironed out now. As keyboard input seems to be the culprit, it's also thinkable that kbdmux(4) has something to do with it. By default kern.evdev.rcpt_mask is set up to use kbdmux(4) and sysmouse(4). You could try setting kern.evdev.rcpt_mask to a value of 12 (0x0C) in /etc/sysctl.conf to use hardware keyboard and hardware mouse instead, to see if it makes any difference in regards to the problem.
From /usr/src/sys/dev/evdev/evdev.h:
Code:/* * Keyboard and mouse events recipient mask. * evdev_rcpt_mask variable should be respected by keyboard and mouse drivers * that are able to send events through both evdev and sysmouse/kbdmux * interfaces so user can choose prefered one to not receive one event twice. */ #define EVDEV_RCPT_SYSMOUSE (1<<0) #define EVDEV_RCPT_KBDMUX (1<<1) #define EVDEV_RCPT_HW_MOUSE (1<<2) #define EVDEV_RCPT_HW_KBD (1<<3) extern int evdev_rcpt_mask;
Since you're still into this, why not consider to contact the respective wizzard/developer(s) via a mailing list and/or on IRC?
doas
came around and required me to update my port collection (DOAS_USER working is essential unless i want to code it in C or switch to sudo
). Really getting to the root of this is likely to require more time than i have patience for right now. So while i'd love to have a clean solution i'll have to postpone it and go for "at least it works" first.#!/bin/sh
exec open -w -- su "$DOAS_USER" -c "exec startx /usr/local/lib/y/x11/session -- -keeptty vt$( vidcontrol -i active )"
permit nopass :mygroup as root cmd /usr/local/lib/y/x11/launch
open
and su
) and i also noticed the following: If doas /usr/local/lib/y/x11/launch
is executed from a shell without exec
there will be garbage in said shell when the X session is closed. X is working flawlessly though. It's also not important for my usecase as execing the doas line ends up at a login prompt after X has exited with no side effects at all and that's basically how i'll use it just that the shell won't be executed to begin with. It's still kinda strange to see this behavior and it reminds one how sub optimal this whole approach is. In any case it works and that's all i care for right now as i want to continue setting up my desktop. Maybe i'll investigate this further at some later point.