Bug 131899 - can't switch to VT1: Ctrl-Alt-F1 generates junk
can't switch to VT1: Ctrl-Alt-F1 generates junk
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Triaged
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-09-06 10:58 EDT by Alexandre Oliva
Modified: 2009-03-11 05:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-17 19:24:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-09-06 10:58:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
rhgb apparently doesn't enable you to switch to VT1 any more.  Is this
on purpose?  This would be very useful to see how fsck is going, for
example.

Ctrl-Alt-F1 generates junk if you have details enabled, instead of
switching to VT1.  FWIW, Ctrl-Alt-Backspace to kill it still works,
but that's a bit too disruptive.

Version-Release number of selected component (if applicable):
rhgb-0.12.3-1

How reproducible:
Always

Steps to Reproduce:
1.Boot with rhgb
2.Try to Ctrl-Alt-F1 after it starts

Actual Results:  Can't.

Expected Results:  Would like to.

Additional info:
Comment 1 Daniel Veillard 2004-09-06 11:42:51 EDT
I didn't touch rhgb recently, I have no idea why this
regression appeared,

Daniel
Comment 2 Bill Nottingham 2004-09-07 00:02:46 EDT
What happens if the vte widget doesn't have keyboard focus?
Comment 3 Daniel Veillard 2004-09-15 07:38:12 EDT
It's X which for some reason desactivates the switch when run
under rhgb, the same X software with the same conf run at init 5
does the right thing. So I short-circuited the way the event is
handled and run "chvt 1", that seems to fix the problem in my
test.

Daniel
Comment 4 Daniel Veillard 2004-09-18 16:48:33 EDT
That should be fixed now in the rawhide version, anything past
0.13.1 should have the fix,

  thanks,

Daniel
Comment 5 Alexandre Oliva 2004-10-02 15:48:24 EDT
Ctrl-Alt-F1 now works, indeed, but F2..F7 still generate junk.

Mike, any idea of why X's behavior within rhgb might have changed so
as to disable VT switching?
Comment 6 Daniel Veillard 2004-10-02 16:18:20 EDT
Why do you want to switch to vt [2-7] ? Sorry I don't
think this adds anything during boot. That's why I did not
implement it.
Please reopen only if there is a good reason to switch at that point.

Daniel
Comment 7 Alexandre Oliva 2004-10-02 16:34:32 EDT
It's not that I'd like to switch to a different VT, it's more like it
broke and we don't know why, and your workaround was hopefully just
that.  We'd better figure out why X changed its behavior instead of
adding yet another layer of duct tape, bubble gum and goat blood :-)
Comment 8 Mike A. Harris 2004-10-03 01:30:50 EDT
Here's my own theory, however let me preface it by saying that I have
not tested or examined this problem directly.  This is only a
_theory_, and subject to change as more details become available,
or the situation is directly investigated.  </disclaimer>

I do not think anything has changed in X that causes this problem,
rather my belief is that we have changed the way X is used, and
that is causing the problem.  Someone mentioned a few weeks back
that using X on a readonly filesystem caused xkb to break, as
it could no longer generate the XKB compiled keymaps when the
server starts.  If rhgb is running on an entirely read-only
filesystem, and the X server can't generate xkb keymaps, then
there will likely be various odd keyboard related problems caused
by this.

Again, this is not a final conclusion, nor even a conclusion at
all really, just purely a personal theory as to what might be
causing this problem.  If this does turn out to be the problem,
then we can explore the issue together, and discuss it on this
weeks X Devel team meeting.

TTYL
Comment 9 Alexandre Oliva 2004-10-05 08:03:22 EDT
mharris, would such xkb errors be logged to the X log file?  DV, does
rhgb preserve this log file anywhere after it umounts /etc/rhgb?
Comment 10 flower 2004-11-23 17:53:26 EST
can anyboday tell me how to disable the VT switching ..
user just wana work on default vt .. 
thankx
jackjill52@hotmail.com
Comment 11 Mike A. Harris 2004-12-03 15:44:29 EST
We've reviewed this problem, and it is indeed caused by the read-only
filesystem environment in which rhgb starts the X server.

The X server invokes xkbcomp, and then tries to read in the files
xkbcomp spits out, however xkbcomp fails because it can't write to
the hard disk.  Since this occurs, the keyboard can't be set up
correctly, and the CTRL-ALT-Fkey functionality needed to switch
VT's is unavailable.

This is not really a bug per se., but rather it is a hard coded
limitation in the current X server infrastructure, which requires
a read-write filesystem currently in order for xkbcomp to work
correctly.

This should be filed in the upstream X.Org bugzilla at:
http://bugs.freedesktop.org in the "xorg" component, as it is
more of a feature request to resolve this.  If someone does
file this upstream, it's possible it might get implemented
sooner.  If so, please paste the upstream bug URL here for us
to track it.

I'm going to mark this bug as an FC4Target feature also, which
we'll review during FC4 development and assess wether this is
a big enough feature to spend time on within the FC4 timeframe.
Comment 13 Mike A. Harris 2005-04-08 08:14:16 EDT
This issue, as mentioned above, occurs because rhgb is invoking the
X server on a read-only filesystem and xkb requires a read-write
filesystem.  Thus, as indicated above, this is a design limitation
of the X server rather than a bug.

Currently, we are planning on removing rhgb and replacing it with
starting gdm earlier on, which will also have this problem.  As such
it is something we want to see the X server enhanced to support
in the future.

Enhancing the X server to handle startup in a read only filesystem
environment is being slated for review and consideration during the
FC5 development cycle.

Changing blocker to FC5Target.
so
Comment 14 Mike A. Harris 2006-01-17 19:24:12 EST
As mentioned above a few times, this is not a bug, but a limitation in the
X server's current infrastructure.  Overcoming this limitation needs to be
an upstream X.Org project.  Please file a bug report or enhancement request
in X.Org bugzilla for this.  It may end up being Red Hatter's that do the
work, but either way, it is an upstream issue that should get tracked
upstream.  Merely filing it there, may even motivate someone to go ahead
and do the work.


Note You need to log in before you can comment on or make changes to this bug.