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:
I didn't touch rhgb recently, I have no idea why this regression appeared, Daniel
What happens if the vte widget doesn't have keyboard focus?
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
That should be fixed now in the rawhide version, anything past 0.13.1 should have the fix, thanks, Daniel
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?
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
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 :-)
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
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?
can anyboday tell me how to disable the VT switching .. user just wana work on default vt .. thankx jackjill52
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.
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
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.