How can I get it to go there and stay there? When starting F21 in multi-user, logging in on tty3 and running startx, KDE shows up on tty3, where, as it's currently broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD. This shouldn't be.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1092852
On Mon, 05.05.14 03:23, Felix Miata (mrmazda@earthlink.net) wrote:
How can I get it to go there and stay there? When starting F21 in multi-user, logging in on tty3 and running startx, KDE shows up on tty3, where, as it's currently broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD. This shouldn't be.
To get the device permissions right startx can only "upgrade" a text session to a graphical one, it cannot open a new VT. Hence if you want X to show up on session N, then you need to start it from ttyN... Note that only tty1-6 get logins by default, but you can configure that with NAutoVTs= in /etc/systemd/logind.conf.
Lennart
On 2014-05-05 12:34 (GMT+0200) Lennart Poettering composed:
Felix Miata wrote:
How can I get it to go there and stay there? When starting F21 in multi-user, logging in on tty3 and running startx, KDE shows up on tty3, where, as it's currently broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD. This shouldn't be.
To get the device permissions right startx can only "upgrade" a text session to a graphical one,
There is a relatively recent change, as it used to be that the first X instance would always start on tty7 no matter how started. I still have a DM running there if in graphical target.
What is this permissions business? IOW, what search terms would lead me to an explanation of the changes, or at least a non-simplistic but not overly detailed why they occurred?
it cannot open a new VT.
Why?
Hence if you want X to show up on session N, then you need to start it from ttyN... Note that only tty1-6 get logins by default, but you can configure that with NAutoVTs= in /etc/systemd/logind.conf.
That sounds like a method that will prevent a DM from running on the same tty as startx would as a first and only X session, as if that hasn't already happened. OT, reading that man page, is setting it 0 how to revert from auto spawning to keeping gettys running on all of tty1-6 as before systemd existed?
On the F21 system booted ATM: systemd-212-2.rc21 xorg.x11.server.Xorg-1.15.99.902-5...fc21 xorg.x11.xauth-1.0.7-4.fc20 Booting graphical.target the DM is on tty7. Booting multi-user.target, logging in on tty3, and from tty3 switching to graphical.target (init 5) also puts the DM on tty7. Startx from tty3 puts X session on tty3 regardless whether DM is running. Why can't startx do whatever systemd did to get X going on tty7? Is there a replacement or substitute for startx that can? Ctrl-Alt-BS fails to kill the startx session. Ctcl-C is unavailable to kill the startx session from bash on tty3 because it's blocked by the broken X session.
Same machine booted to openSUSE Factory (target release November): systemd-210-6.1 xorg.x11.server-7.6_1.15.99.902.2-312.11 xauth-1.0.8-11.1 Booting graphical.target the DM is on tty7. Booting multi-user.target, logging in on tty3, and from tty3 switching to graphical.target (init 5) also puts the DM on tty7. Startx -- :1 from tty3 with DM running puts X session on tty8 (same as happened in Fedora 5 years ago). Ctrl-Alt-BS succeeds to kill the X session. Ctrl-C on tty3 also will kill the X session started from it. All is same with DM not running (in multi-user.target) with simple startx, except the startx session is on tty7. Where X sessions land is nicely same as in e.g. F7 & F14.
I might not even care about the location of X sessions if only it wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS not work any more?
On Mon, 05.05.14 11:45, Felix Miata (mrmazda@earthlink.net) wrote:
On 2014-05-05 12:34 (GMT+0200) Lennart Poettering composed:
Felix Miata wrote:
How can I get it to go there and stay there? When starting F21 in multi-user, logging in on tty3 and running startx, KDE shows up on tty3, where, as it's currently broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD. This shouldn't be.
To get the device permissions right startx can only "upgrade" a text session to a graphical one,
There is a relatively recent change, as it used to be that the first X instance would always start on tty7 no matter how started. I still have a DM running there if in graphical target.
It's has been that way since Fedora adopted systemd, which was in F15 or so IIRC? That makes 3.5y or so...
On Fedora tty1 is the graphical login, since a long time.
What is this permissions business? IOW, what search terms would lead me to an explanation of the changes, or at least a non-simplistic but not overly detailed why they occurred?
Dunno, it's about making sure logind knows about your session and on which VT it is, so that switching to/from it works correctly, and so that we can managed access to your audio cards and similar properly. And since very recently even access to input and gfx devices is managed by logind, so this becomes even more important.
it cannot open a new VT.
Why?
Because you'd have to register that new VT with logind, and there's no way currently to do that, since creating a session is a one-way street, and you cannot create another session from an existing one, without involving some background process that is not part of any session. And nobody wrote such a daemon yet.
Hence if you want X to show up on session N, then you need to start it from ttyN... Note that only tty1-6 get logins by default, but you can configure that with NAutoVTs= in /etc/systemd/logind.conf.
That sounds like a method that will prevent a DM from running on the same tty as startx would as a first and only X session, as if that hasn't already happened. OT, reading that man page, is setting it 0 how to revert from auto spawning to keeping gettys running on all of tty1-6 as before systemd existed?
I cannot parse this.
Lennart
On 2014-05-05 17:55 (GMT+0200) Lennart Poettering composed:
On Fedora tty1 is the graphical login, since a long time.
I've managed to avoid that in order that my boot messages tail stays there undisturbed until such time as I've run out of vttys and need to use a sixth, the way I like it, same as last century. Change isn't always improvement.
Hence if you want X to show up on session N, then you need to start it from ttyN... Note that only tty1-6 get logins by default, but you can configure that with NAutoVTs= in /etc/systemd/logind.conf.
That sounds like a method that will prevent a DM from running on the same tty as startx would as a first and only X session, as if that hasn't already happened. OT, reading that man page, is setting it 0 how to revert from auto spawning to keeping gettys running on all of tty1-6 as before systemd existed?
I cannot parse this.
There are two parts to it. WRT part 2, as I wrote, OT WRT thread, I looked at the logind.conf man page section NAutoVTs= and was wondering if by setting it to 0 auto spawning vts could be dispensed with entirely so that gettys could run there continuously from the outset as they used to. Full screen sessions with bigger text are good for the eyes, so I use them a lot. I have a problem understanding that man page paragraph.
WRT part 1, I don't see from reading that man page how NAutoVTs= could do anything to enable and/or further a first and only X session regardless how started to run unconditionally on tty7.
On Mon, 05.05.14 12:24, Felix Miata (mrmazda@earthlink.net) wrote:
On 2014-05-05 17:55 (GMT+0200) Lennart Poettering composed:
On Fedora tty1 is the graphical login, since a long time.
I've managed to avoid that in order that my boot messages tail stays there undisturbed until such time as I've run out of vttys and need to use a sixth, the way I like it, same as last century. Change isn't always improvement.
Hmm, well, this is Fedora, the bleeding edge of Linux development. You'll not find everything supported exactly the same way as 1989.
There are better ways to get boot itme log output. For example "journalctl -b".
That sounds like a method that will prevent a DM from running on the same tty as startx would as a first and only X session, as if that hasn't already happened. OT, reading that man page, is setting it 0 how to revert from auto spawning to keeping gettys running on all of tty1-6 as before systemd existed?
I cannot parse this.
There are two parts to it. WRT part 2, as I wrote, OT WRT thread, I looked at the logind.conf man page section NAutoVTs= and was wondering if by setting it to 0 auto spawning vts could be dispensed with entirely so that gettys could run there continuously from the outset as they used to. Full screen sessions with bigger text are good for the eyes, so I use them a lot. I have a problem understanding that man page paragraph.
You don't even need to set NAutoVT to 0 for that, you can simply instantiate as many getty instances as you wish by symlinking getty@.service from /usr/lib/systemd/system/ into /etc/systemd/system/getty.wants/getty@tty2.service and so on...
WRT part 1, I don't see from reading that man page how NAutoVTs= could do anything to enable and/or further a first and only X session regardless how started to run unconditionally on tty7.
logind will not configure how X works.
Lennart
On Mon, May 05, 2014 at 11:45:31AM -0400, Felix Miata wrote:
I might not even care about the location of X sessions if only it wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS not work any more?
On 2014-05-06 11:04 (GMT+1000) Peter Hutterer composed:
On Mon, May 05, 2014 at 11:45:31AM -0400, Felix Miata wrote:
I might not even care about the location of X sessions if only it wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS not work any more?
Are you by providing that link in any way suggesting that there's been a keymap change that needs a user adjustment (for KDE users anyway if not others)? It provides no help where to look to make it happen globally in a post-sysvinit world.
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"
somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
They still get the job done in Cauldron's 1.15.99.902, Factory's 1.15.99.902.2 and Linux Mint LMDE (aka Debian Jessie/Sid) 1.14.3.
On 05/05/2014 09:21 PM, Felix Miata wrote:
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection
Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection
On 2014-05-06 00:13 (GMT-0700) Samuel Sieb composed:
Felix Miata wrote:
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"
somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection
Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection
Thank you!
Turns out DontZap works with either false or off, but the difference between SUSE and Fedora is the addtional need for XkbOptions in Fedora, and here's why:
/usr/share/X11/xkb/rules/ --- evdev 2014-01-29 22:45:32.000000000 -0500 +++ evdev-suse 2014-04-09 15:51:53.000000000 -0400 @@ -857,9 +857,9 @@ * yu unicodeyz = +srp(latinunicodeyz):4
! model = symbols - $evdevkbds = +inet(evdev)+inet(%m) - applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys) - * = +inet(evdev) + $evdevkbds = +inet(evdev)+inet(%m)+terminate(ctrl_alt_bksp) + applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)+terminate(ctrl_alt_bksp) + * = +inet(evdev)+terminate(ctrl_alt_bksp)
! model layout = symbols
Using the SUSE evdev file in place of Fedora's my original xorg.con* that used to work also in Fedora works in it again without need for the XkbOptions addition.
On Tue, May 06, 2014 at 06:15:12AM -0400, Felix Miata wrote:
On 2014-05-06 00:13 (GMT-0700) Samuel Sieb composed:
Felix Miata wrote:
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection
Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection
fwiw (only answering one email) this is what systemd-localed should drop into /etc/X11/xorg.conf.d/00-keyboard.conf, with configuration based on whatever language settings you picked. so you shouldn't need this section.
Thank you!
Turns out DontZap works with either false or off, but the difference
the option parser in X is entertaining. "no", "off", "false", and "0" all work to disable, and so does prefixing the option with "No". So Option "NoDontZap" "off" is valid, just don't expect anyone to understand a triple-negation :) you can also sprinkle random whitespaces or underscores in there, in case you have too many of them.
Cheers, Peter
between SUSE and Fedora is the addtional need for XkbOptions in Fedora, and here's why:
/usr/share/X11/xkb/rules/ --- evdev 2014-01-29 22:45:32.000000000 -0500 +++ evdev-suse 2014-04-09 15:51:53.000000000 -0400 @@ -857,9 +857,9 @@
yu unicodeyz = +srp(latinunicodeyz):4! model = symbols
- $evdevkbds = +inet(evdev)+inet(%m)
- applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)
= +inet(evdev)
- $evdevkbds = +inet(evdev)+inet(%m)+terminate(ctrl_alt_bksp)
- applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)+terminate(ctrl_alt_bksp)
= +inet(evdev)+terminate(ctrl_alt_bksp)! model layout = symbols
Using the SUSE evdev file in place of Fedora's my original xorg.con* that used to work also in Fedora works in it again without need for the XkbOptions addition. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 2014-05-07 21:09 (GMT+1000) Peter Hutterer composed:
Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection
fwiw (only answering one email) this is what systemd-localed should drop into /etc/X11/xorg.conf.d/00-keyboard.conf, with configuration based on whatever language settings you picked. so you shouldn't need this section.
An F21 boot to multiuser, delete of 00-keyboard.conf, and then startx leaves /etc/X11/xorg.conf.d/ void of 00-keyboard.conf, so apparently systemd-localed currently drops nothing at all there.
Turns out DontZap works with either false or off, but the difference
the option parser in X is entertaining. "no", "off", "false", and "0" all work to disable, and so does prefixing the option with "No". So Option "NoDontZap" "off" is valid, just don't expect anyone to understand a triple-negation :) you can also sprinkle random whitespaces or underscores in there, in case you have too many of them.
answering to the subject
my /etc/X11/xorg.conf is:
Section "ServerLayout" Identifier "single head configuration" Option "DontZap" "false" Option "DontZoom" "false" EndSection
On Qua, 2014-05-07 at 21:09 +1000, Peter Hutterer wrote:
On Tue, May 06, 2014 at 06:15:12AM -0400, Felix Miata wrote:
On 2014-05-06 00:13 (GMT-0700) Samuel Sieb composed:
Felix Miata wrote:
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
I use the following that works on F20: # cat /etc/X11/xorg.conf.d/99-zap.conf Section "ServerFlags" Option "DontZap" "false" EndSection
Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection
fwiw (only answering one email) this is what systemd-localed should drop into /etc/X11/xorg.conf.d/00-keyboard.conf, with configuration based on whatever language settings you picked. so you shouldn't need this section.
Thank you!
Turns out DontZap works with either false or off, but the difference
the option parser in X is entertaining. "no", "off", "false", and "0" all work to disable, and so does prefixing the option with "No". So Option "NoDontZap" "off" is valid, just don't expect anyone to understand a triple-negation :) you can also sprinkle random whitespaces or underscores in there, in case you have too many of them.
Cheers, Peter
between SUSE and Fedora is the addtional need for XkbOptions in Fedora, and here's why:
/usr/share/X11/xkb/rules/ --- evdev 2014-01-29 22:45:32.000000000 -0500 +++ evdev-suse 2014-04-09 15:51:53.000000000 -0400 @@ -857,9 +857,9 @@
yu unicodeyz = +srp(latinunicodeyz):4! model = symbols
- $evdevkbds = +inet(evdev)+inet(%m)
- applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)
= +inet(evdev)
- $evdevkbds = +inet(evdev)+inet(%m)+terminate(ctrl_alt_bksp)
- applealu_jis = +inet(evdev)+macintosh_vndr/jp(alujiskeys)+terminate(ctrl_alt_bksp)
= +inet(evdev)+terminate(ctrl_alt_bksp)! model layout = symbols
Using the SUSE evdev file in place of Fedora's my original xorg.con* that used to work also in Fedora works in it again without need for the XkbOptions addition. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 2014-05-07 18:22 (GMT+0100) Sérgio Basto composed:
answering to the subject
my /etc/X11/xorg.conf is:
Section "ServerLayout" Identifier "single head configuration" Option "DontZap" "false" Option "DontZoom" "false" EndSection
In what way does that answer anything? Unless you are using a UMS video driver, I doubt DontZoom has any effect on anything. Does Ctrl-Alt-Bksp do anything on your system? If so, what locale do you use, and which video driver?
Am 07.05.2014 19:41, schrieb Felix Miata:
On 2014-05-07 18:22 (GMT+0100) Sérgio Basto composed:
answering to the subject
my /etc/X11/xorg.conf is:
Section "ServerLayout" Identifier "single head configuration" Option "DontZap" "false" Option "DontZoom" "false" EndSection
In what way does that answer anything? Unless you are using a UMS video driver, I doubt DontZoom has any effect on anything. Does Ctrl-Alt-Bksp do anything on your system? If so, what locale do you use, and which video driver?
that bring sme back to the login-creen on any pyhsical machine with Ctrl-Alt-Bksp over years
[root@srv-rhsoft:/etc/X11/xorg.conf.d]$ cat 00-keyboard.conf Section "InputClass" Identifier "system-setup-keyboard" MatchIsKeyboard "on" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" Option "XkbOptions" "terminate:ctrl_alt_bksp," EndSection
On Qua, 2014-05-07 at 19:45 +0200, Reindl Harald wrote:
Am 07.05.2014 19:41, schrieb Felix Miata:
On 2014-05-07 18:22 (GMT+0100) Sérgio Basto composed:
answering to the subject
my /etc/X11/xorg.conf is:
Section "ServerLayout" Identifier "single head configuration" Option "DontZap" "false" Option "DontZoom" "false" EndSection
In what way does that answer anything? Unless you are using a UMS video driver, I doubt DontZoom has any effect on anything. Does Ctrl-Alt-Bksp do anything on your system? If so, what locale do you use, and which video driver?
yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
Option "XkbOptions" "terminate:ctrl_alt_bksp,
cat /etc/X11/xorg.conf.d/00-keyboard.conf
Section "InputClass" Identifier "system-setup-keyboard" MatchIsKeyboard "on" Option "XkbModel" "pc105" Option "XkbLayout" "pt" Option "XkbOptions" "terminate:ctrl_alt_bksp," EndSection
my video card is : [ 52.601] (II) intel(0): [DRI2] DRI driver: i965
"DontZoom" don't works , you are right
that bring sme back to the login-creen on any pyhsical machine with Ctrl-Alt-Bksp over years
[root@srv-rhsoft:/etc/X11/xorg.conf.d]$ cat 00-keyboard.conf Section "InputClass" Identifier "system-setup-keyboard" MatchIsKeyboard "on" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" Option "XkbOptions" "terminate:ctrl_alt_bksp," EndSection
On 2014-05-07 19:03 (GMT+0100) Sérgio Basto composed:
yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
Option "XkbOptions" "terminate:ctrl_alt_bksp,
cat /etc/X11/xorg.conf.d/00-keyboard.conf
Option "XkbModel" "pc105" Option "XkbLayout" "pt" Option "XkbOptions" "terminate:ctrl_alt_bksp,"
my video card is : [ 52.601] (II) intel(0): [DRI2] DRI driver: i965
"DontZoom" don't works , you are right
Your (locale pt) and Reindl's (locale de) answers beg two questions:
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
Just adding my two cents as I don't use the us locale.
On Wednesday 07 May 2014 14:38:59 Felix Miata wrote:
On 2014-05-07 19:03 (GMT+0100) Sérgio Basto composed:
yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
The es locale doesn't have a terminate subsection...:
# Read and parsed by systemd-localed. It's probably wise not to edit this file # manually too freely. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "es,si,rs" Option "XkbVariant" ",," Option "XkbOptions" "grp:lalt_lshift_toggle" EndSection
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
I installed my Fedora from a network install image, and the three locales I have were the languages I itold anaconda I wanted support for. Hence, at least for me, it was the system installation which created it.
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
My case was a clean install.
On 2014-05-07 20:49 (GMT+0200) Fidel Leon composed:
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
My case was a clean install.
Every install had to be a clean install by going far enough back in time. The question remains when you did a clean install, as retirement of the keyboard driver was recent, and may have occurred after your clean installation.
On Wednesday 07 May 2014 16:01:53 Felix Miata wrote:
On 2014-05-07 20:49 (GMT+0200) Fidel Leon composed:
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
My case was a clean install.
Every install had to be a clean install by going far enough back in time.
Yes, of course, my point was saying "I haven't upgraded from past releases", no old files which could carry such setup.
Anyway:
# ll -dt /boot/grub2/grub.cfg /boot/lost+found/ /boot/initramfs-3.14.2-200.fc20.i686+PAE.img /etc/X11/xorg.conf.d/00-keyboard.conf -rw-------. 1 root root 4799 May 4 00:05 /boot/grub2/grub.cfg -rw-------. 1 root root 19034041 May 4 00:04 /boot/initramfs-3.14.2-200.fc20.i686+PAE.img -rw-r--r--. 1 root root 324 May 4 00:02 /etc/X11/xorg.conf.d/00-keyboard.conf drwx------. 2 root root 12288 May 3 20:38 /boot/lost+found/
That was four days ago - exactly when I (re)installed F20. I did a network installation, so most installed packages were already in the most current versions. Hence, in some moment after package installation but before the dracut and grub installation steps, was my keyboard file created (.conf file which follows what anaconda wrote in the kickstart files).
That's consistent with what I see on another system I manage, which used a Xfce live CD to be installed.
Am 07.05.2014 20:38, schrieb Felix Miata:
On 2014-05-07 19:03 (GMT+0100) Sérgio Basto composed:
yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
Option "XkbOptions" "terminate:ctrl_alt_bksp,
cat /etc/X11/xorg.conf.d/00-keyboard.conf
Option "XkbModel" "pc105" Option "XkbLayout" "pt" Option "XkbOptions" "terminate:ctrl_alt_bksp,"my video card is : [ 52.601] (II) intel(0): [DRI2] DRI driver: i965
"DontZoom" don't works , you are right
Your (locale pt) and Reindl's (locale de) answers beg two questions:
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
because nobody did write it there?
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
not what - who - a smart admin in my case which just used google years ago: https://bbs.archlinux.org/viewtopic.php?pid=602885
On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:
On 2014-05-07 19:03 (GMT+0100) Sérgio Basto composed:
yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
Option "XkbOptions" "terminate:ctrl_alt_bksp,
cat /etc/X11/xorg.conf.d/00-keyboard.conf
Option "XkbModel" "pc105" Option "XkbLayout" "pt" Option "XkbOptions" "terminate:ctrl_alt_bksp,"my video card is : [ 52.601] (II) intel(0): [DRI2] DRI driver: i965
"DontZoom" don't works , you are right
Your (locale pt) and Reindl's (locale de) answers beg two questions:
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
systemd-localed. This file is written when you change the locale, either during install or later with localectl. It doesn't automatically get restored when you delete it.
http://fedoraproject.org/wiki/Input_device_configuration lists the magic command as: localectl set-x11-keymap "us" "" "" "terminate:ctrl_alt_bksp"
which communicates the new keymap to systemd-localed, which then writes out the file.
but having just tested this on F20, just running "localectl set-keymap us" also writes out the right configuration, including the terminate option. The above is needed for custom x11 keymaps, but shouldn't be needed for normal setup.
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
neither the keyboard nor the evdev driver have anything to do with it. the retirement of the keyboard driver should have no effect on anything newer than, say, Fedora 12.
Zapping in the server works as a two-stage process. A key combination is interpreted by a XKB as a Terminate_Server action. The server then interprets that and terminates. With DontZap you only control the second part, i.e. whether the server terminates when the action is triggered. If you don't have the XKB setting, you can't trigger it in the first place. And DontZap is only useful if you want to _prohibit_ zapping completely. It just makes Terminate_Server do nothing.
For your use-case, forget about DontZap, it has no effect. I'm the maintainer for these parts of the server, so regardless of how many configurations you find that tell you to enable it, please trust my word here. You need to get the terminate XKB option into your keymap, that's all that matters.
Cheers, Peter
On 2014-05-08 08:43 (GMT+1000) Peter Hutterer composed:
On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:
Your (locale pt) and Reindl's (locale de) answers beg two questions:
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
systemd-localed. This file is written when you change the locale, either during install or later with localectl. It doesn't automatically get restored when you delete it.
http://fedoraproject.org/wiki/Input_device_configuration lists the magic command as: localectl set-x11-keymap "us" "" "" "terminate:ctrl_alt_bksp"
On a Rawhide system originally installed 6 weeks ago running in multi-user I deleted 00-keyboard.conf, then did yum upgrade, and before rebooting the new kernel tried that command, with these results:
Failed to set keymap: Connection timed out new 00-keyboard.conf not written I had to force a reboot, as most anything I tried related to shutting down timed out.
After reboot it succeeded, but I still wonder why CAD gets enabled there at installation time for pt and de by not us. :-(
which communicates the new keymap to systemd-localed, which then writes out the file.
but having just tested this on F20, just running "localectl set-keymap us" also writes out the right configuration, including the terminate option. The above is needed for custom x11 keymaps, but shouldn't be needed for normal setup.
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
neither the keyboard nor the evdev driver have anything to do with it. the retirement of the keyboard driver should have no effect on anything newer than, say, Fedora 12.
Zapping in the server works as a two-stage process. A key combination is interpreted by a XKB as a Terminate_Server action. The server then interprets that and terminates. With DontZap you only control the second part, i.e. whether the server terminates when the action is triggered. If you don't have the XKB setting, you can't trigger it in the first place. And DontZap is only useful if you want to _prohibit_ zapping completely. It just makes Terminate_Server do nothing.
For your use-case, forget about DontZap, it has no effect. I'm the maintainer for these parts of the server, so regardless of how many configurations you find that tell you to enable it, please trust my word here. You need to get the terminate XKB option into your keymap, that's all that matters.
FWIW, on one F21 system with radeon video here even a normal exit from a startx KDE session is leaving the screen on the tty started from black. A shift to a tty and back then draws what had been expected. I've tried on 6+ other installations, one with radeon, and all the others behave as expected.
On Thu, May 08, 2014 at 11:43:08PM -0400, Felix Miata wrote:
On 2014-05-08 08:43 (GMT+1000) Peter Hutterer composed:
On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:
Your (locale pt) and Reindl's (locale de) answers beg two questions:
1-why do 00-keyboard.conf for pt and de contain terminate:ctrl_alt_bksp, but for locale us it is absent?
2-what creates 00-keyboard.conf in the first place, since it doesn't get automatically recreated even by rebooting if deleted?
systemd-localed. This file is written when you change the locale, either during install or later with localectl. It doesn't automatically get restored when you delete it.
http://fedoraproject.org/wiki/Input_device_configuration lists the magic command as: localectl set-x11-keymap "us" "" "" "terminate:ctrl_alt_bksp"
On a Rawhide system originally installed 6 weeks ago running in multi-user I deleted 00-keyboard.conf, then did yum upgrade, and before rebooting the new kernel tried that command, with these results:
Failed to set keymap: Connection timed out new 00-keyboard.conf not written I had to force a reboot, as most anything I tried related to shutting down timed out.
loginctl doesn't write the file, it talks over dbus to systemd-logind which writes out the file. This is the connection that failed, for some reason.
After reboot it succeeded, but I still wonder why CAD gets enabled there at installation time for pt and de by not us. :-(
what's in your /etc/vconsole.conf? We've now reached a point where it's better to file a bug report though.
Cheers, Peter
which communicates the new keymap to systemd-localed, which then writes out the file.
but having just tested this on F20, just running "localectl set-keymap us" also writes out the right configuration, including the terminate option. The above is needed for custom x11 keymaps, but shouldn't be needed for normal setup.
re 2: Maybe your two installations have 00-keyboard.conf carried over from before xorg-x11-drv-keyboard was superceded by xorg-x11-drv-evdev, which on (re)installation does not create it if it does not exist?
neither the keyboard nor the evdev driver have anything to do with it. the retirement of the keyboard driver should have no effect on anything newer than, say, Fedora 12.
Zapping in the server works as a two-stage process. A key combination is interpreted by a XKB as a Terminate_Server action. The server then interprets that and terminates. With DontZap you only control the second part, i.e. whether the server terminates when the action is triggered. If you don't have the XKB setting, you can't trigger it in the first place. And DontZap is only useful if you want to _prohibit_ zapping completely. It just makes Terminate_Server do nothing.
For your use-case, forget about DontZap, it has no effect. I'm the maintainer for these parts of the server, so regardless of how many configurations you find that tell you to enable it, please trust my word here. You need to get the terminate XKB option into your keymap, that's all that matters.
FWIW, on one F21 system with radeon video here even a normal exit from a startx KDE session is leaving the screen on the tty started from black. A shift to a tty and back then draws what had been expected. I've tried on 6+ other installations, one with radeon, and all the others behave as expected. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, 2014-05-13 at 09:56 +1000, Peter Hutterer wrote:
After reboot it succeeded, but I still wonder why CAD gets enabled there at installation time for pt and de by not us. :-(
what's in your /etc/vconsole.conf? We've now reached a point where it's better to file a bug report though.
This could get messy.
For one thing I suspect i may be to do with it being the default layout; perhaps this means anaconda never explicitly calls localed to write out a config if you never change the layout from us. I'd have to dig into anaconda to make sure.
The thing that makes it messy, though, is the vestigial bit of system-config-keyboard / system-setup-keyboard that systemd/localed is still lugging around, the Magic List of keyboard layouts called kbd-model-map . It's in /usr/share/systemd/kbd-model-map on an installed system, src/locale/kbd-model-map in a systemd git checkout.
A layout setting operation that gets run through that list is probably going to get the terminate:ctrl_alt_bksp option set, because it's listed in the 'xoptions' column of kbd-model-map for every layout that file contains.
I no longer recall exactly when localed does and possibly does not use kbd-model-map. I'd have to investigate a bit. And there may be other wrinkles around the place. But that's at least one place to look. (An obvious first test is to try an install with two similar non-default keyboard layouts, one that's listed in kbd-model-map and one that isn't, and see what happens).
On Tue, May 06, 2014 at 12:21:05AM -0400, Felix Miata wrote:
On 2014-05-06 11:04 (GMT+1000) Peter Hutterer composed:
On Mon, May 05, 2014 at 11:45:31AM -0400, Felix Miata wrote:
I might not even care about the location of X sessions if only it wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS not work any more?
Are you by providing that link in any way suggesting that there's been a keymap change that needs a user adjustment (for KDE users anyway if not others)? It provides no help where to look to make it happen globally in a post-sysvinit world.
there is no "globally" and it has nothing to do with being post-sysvinit. you can add it to the default options on startup with an InputClass section (which we do, check /etc/X11/xorg.conf.d/00-keyboard.conf) so it'll work out of the box until something overwrites the user's keymap. That something could be gdm or your desktop environment, ymmv.
if you want it set for your user in GNOME, install gnome-tweak-tool, it's in Typing, iirc. Other desktops have other ways to configure it, but I don't know those off-heart.
For years, probably since the time of that document, I've had
Option "DontZap" "off" Option "ZapWarning" "off"
somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but
DontZap disallows zapping completely, regardless of your xkb settings. But you're setting it to what is the default, so it has no effect. ZapWarning is not an option in Fedora, it's an old SuSE patch that never got merged upstream. Your config has no effect since X server 1.6 or possibly longer.
only in Fedora (at least as far back as F14, worked as recent at least as F8), so far that I've noticed.
F11 had this change, judging by the package names I linked to in that blog post.
They still get the job done in Cauldron's 1.15.99.902, Factory's 1.15.99.902.2 and Linux Mint LMDE (aka Debian Jessie/Sid) 1.14.3.
yeah, and Fedora stays close to upstream, so we don't have those patches.
Cheers, Peter
Hi,
On 05/05/2014 05:45 PM, Felix Miata wrote:
On 2014-05-05 12:34 (GMT+0200) Lennart Poettering composed:
Felix Miata wrote:
How can I get it to go there and stay there? When starting F21 in multi-user, logging in on tty3 and running startx, KDE shows up on tty3, where, as it's currently broken[1], it needs to be killed to escape it. Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose), and switching to tty3 is unavailable to use Ctrl-C to kill it as can be done when started from tty3 but running on tty7. The only way out is logging in somewhere else, or CAD. This shouldn't be.
To get the device permissions right startx can only "upgrade" a text session to a graphical one,
There is a relatively recent change, as it used to be that the first X instance would always start on tty7 no matter how started. I still have a DM running there if in graphical target.
What is this permissions business? IOW, what search terms would lead me to an explanation of the changes, or at least a non-simplistic but not overly detailed why they occurred?
it cannot open a new VT.
Why?
Part of the reasons are explained here: http://hansdegoede.livejournal.com/14268.html
Note that this only is valid from F-21 on-wards, but it is strongly related to why it cannot be done either in F-20.
Regards,
Hans
Felix Miata wrote:
Ctrl-Alt-BS fails to kill it (in spite of xorg.con* entries intended that Ctrl-Alt-BS be enabled for that purpose
For the future, Ctrl+Alt+BkSp can be enabled in KDE System Settings under "Keyboard Layouts / Advanced". (It's an xkb option.)
(And I still think that it was a mistake to disable it by default to begin with!)
Kevin Kofler
-
Adam Williamson -
Felix Miata -
Fidel Leon -
Hans de Goede -
Kevin Kofler -
Lennart Poettering -
Peter Hutterer -
Reindl Harald -
Samuel Sieb -
Sérgio Basto