Bug 80694
Summary: | Low-level typematic setting causes console screen switch | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | jw1233219 |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | mitr |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-01-08 06:26:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jw1233219
2002-12-30 00:44:43 UTC
I don't quite understand the precice detailed steps in order to attempt to reproduce. Could you expand step by step, with exact details? I've always had 12-24 consoles configured in inittab since 1995 or so, and have never encountered random VT switching like described above, so I would like to make absolutely positive of the exact steps to reproduce. Attach your /etc/inittab, X log, and config file please along with the details. Thanks. This possibly only happens when using startx to bring up X. That is how I usually have things configured. I also have a different keymap that maps Delete to Delete and Backspace to Backspace instead of the usual strange US.map. I have also patched and recompiled my XFree86 with the typematic stuff commented out. This fixes the problem. But at this point in time I am not prepared to undo everything and go back just to get some logs etc. My initiab is nothing special - just extra mingetty's and runlevel of 5. But I have screen :0 commented out of my Xservers file. I suggest that you start your testing by preventing the xdm startup of local screen :0 and see what happens when you log in to, say virtual console 1, and type startx. Well, if there is a problem here at all, it definitely is not a Red Hat Linux specific problem as we aren't patching the code in any ways that could cause the behaviour you describe, so it would be a generic XFree86 problem. Since you're the first to report such a problem, I doubt that if it is an actual software bug that it is affecting very many users at all. If you're not willing to provide me with log files and information that I've requested above, then you seem satisfied with your own workaround, and I'm not going to waste time tracking down something that is potentially just some weird issue on your own local system. If you believe this is indeed a bug in XFree86, then I suggest reporting it to XFree86.org directly by using the xpert mailing list, and xfree86 bug report address. Inability to reproduce this on 2 systems makes this a non-priority issue for me to investigate further without co-operation from you. Closing as WORKSFORME. I reported this to XFree over a year ago. The same problem occurred on complete different hardware (different keyboard and motherboard and with RH7.0 and RH7.2 and now RH8.0). But one does wonder why the default RH distribution is configured with only 6 VTs so that VT6 is used for X (that is what the glitch causes a switch to - handy coincidence!). If you look at the XFree code you will see the inb() and outb()'s that are used to zap the keyboard. Given that the kernel already has a driver for the keyboard active it is small wonder that things get temporarily screwed. But you are right. Why bother? No one else complains because they probably use the default configuration. And those that do probably just attribute it to typically flakey linux desktops. BTW it has something to do with the fact that the kernel returns EINVAL from KDKBDREP, so the code falls beack to direct port i/o. Have a nice day. Sorry to waste your time (and, more importantly, because I dont get paid for this - my time). >I reported this to XFree over a year ago. The same problem occurred on >complete different hardware (different keyboard and motherboard and with >RH7.0 and RH7.2 and now RH8.0). How did you report it exactly? What email address did you report to? I can ping someone there to investigate your report if it got lost in the pile somehow. >But one does wonder why the default RH distribution >is configured with only 6 VTs Well, that is basically because it has been standard practice in all Linux distributions basically since the dawn of time to preconfigure 6 VCs in inittab, and most documentation assumes 6 preconfigured VCs. Most Linux X related documentation also assumes that 6 VCs are the default as it mentions X starting on VC 7 in countless places. >so that VT6 is used for X No, X by default uses the first unused tty unless you manually specify a specific VC to start on using an X server commandline option. Since all Linux distributions (not just Red Hat) default to using 6 VCs, X starts up on VC 7 (/dev/tty7) by default in all Linux distributions. >(that is what the glitch causes a switch to - handy coincidence!). I don't see any coincidence here, since it is tty7 that the X server is physically running on, and not tty6 as you imply above. >If you look at the XFree code you will see the inb() and outb()'s that >are used to zap the keyboard. Given that the kernel already has a driver >for the keyboard active it is small wonder that things get temporarily >screwed. I wonder why only one person has ever reported this? As I stated before, *I* run more than 6 virtual consoles on all my Linux machines, and I always have, since 1995 if not earlier. Across every release of Slackware up until 1997, and every release of Red Hat Linux since 4.2. I have _never_ encountered this problem on tonnes of machines. I am not saying there _isnt_ a problem, just that I have not ever experienced it, and using your above info, I am unable to do so currently either. >But you are right. Why bother? No one else complains because they probably >use the default configuration. And those that do probably just attribute >it to typically flakey linux desktops. That is bogus. I have never encountered this problem in 7 years of heavy Linux usage on many different computers across many XFree86 releases on many distributions. I've not seen any bug reports of this nature ever other than yours right now, and I am unable so far to reproduce the problem you are claiming exists. If this problem is really a problem, and it bothers you so greatly, you would provide the information requested, and you would work WITH developers instead of AGAINST them, and you would do so politely rather than ranting. If I were to chase every single bug that a user reports and is adamant about, a good 50% if not more of them would waste my time chasing bugs that are end user misconfiguration, or end user self-compiled-kernel problems, or other similar end user invoked problems. I don't have time to do that, which is why I ask people to provide me with as many details as possible for their problems. Again, please take this issue upstream to XFree86.org as it is not reproduceable by me given the supplied information above, and considering the plethora of other problems that are actually reproduceable, and the triviality of this one which is not, it is not going to get any priority here. Closing again as WORKSFORME, on a Compaq Proliant ML530, a Tyan HEsl 2567, an Acer AMD 486DX2/66, a VIA TXPro motherboard, an Itanium 2, and another MSI board. Exact steps to reproduce the problem: 1. Modify /usr/kbd/keymaps/i386/qwerty/us.map.gz by adding "keycode 93 = Console_6" 2. Re-load it with "loadkeys us" 3. Type "startx" 4. Voila! You get VT6 instead of the correct VT with X. The low-level XFree code which zaps the keyboard causes the emission of a "false" keycode. It is just that not many people (in fact I suspect I might be the only one) has anything mapped to keycode 93. What exactly is the purpose of editing the keymap files at all? On a default installation of Red Hat Linux, there are 6 virtual consoles, and X will open the first free one which is tty7. Without modifying /etc/inittab, you can switch between any of the consoles using ALT-F1 through ALT-F7 from the console, or by using ALT-LEFTARROW/ALT-RIGHTARROW. This is standard default console configuration. If you add entries for other consoles to /etc/inittab, then the system will automatically use them also. To illustrate my point, here is my inittab: 1:2345:respawn:/sbin/mingetty tty1 --noclear 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 7:2345:respawn:/sbin/mingetty tty7 8:2345:respawn:/sbin/mingetty tty8 9:2345:respawn:/sbin/mingetty tty9 10:2345:respawn:/sbin/mingetty tty10 11:2345:respawn:/sbin/mingetty tty11 12:2345:respawn:/sbin/mingetty tty12 13:2345:respawn:/sbin/mingetty tty13 14:2345:respawn:/sbin/mingetty tty14 15:2345:respawn:/sbin/mingetty tty15 16:2345:respawn:/sbin/mingetty tty16 17:2345:respawn:/sbin/mingetty tty17 18:2345:respawn:/sbin/mingetty tty18 19:2345:respawn:/sbin/mingetty tty19 20:2345:respawn:/sbin/mingetty tty20 21:2345:respawn:/sbin/mingetty tty21 22:2345:respawn:/sbin/mingetty tty22 When the system starts up, 22 virtual consoles are created with mingetty logins, the first of which I have added the --noclear option to. ALT-F1 through ALT-F12 selects consoles 1 to 12, and RIGHT_ALT-F1 through RIGHT_ALT-F12 selects consoles 13 to 24. I start up X using "startx" with sufficient commandline options to make it start on tty24 which is where I want it to be. I am able to switch to whatever terminal both inside and outside X, and I do not need to edit any console nor X keymaps to do so. I also do not experience the problem you are describing, nor do I understand why you feel the need to edit the keymap. If there is a bug here, and I'm not acknowledging that there is, it is NOT something that is going to be fixed by Red Hat, nor in Red Hat Linux. It is something that MUST be done by XFree86.org before I will even acknowledge it. I am closing this as WONTFIX this time to differentiate it from WORKSFORME, in that if there is a bug, it is not going to be fixed, at least not here. If you were unsuccessful in getting XFree86.org to fix it or to look at your patch, then perhaps you should try talking to them again, and establish 2 way communication. Do not reopen this report again please, as that is a pointless waste of both of our time. I've indicated it is WONTFIX, and that isn't going to change. As far as I'm concerned, your keyboard is broken. Your additional information was absolutely pointless. So what you are saying is that Redhat has never contributed to a fix for a product that they don't "own"? Is that what the open source community is about? Have a nice day and I hope you never use a keyboard made outside of the USA for non-USA users or non-English language etc. BTW my keyboard is NOT broken, and if your analysis has drawn that conclusion then it is definitely flawed. The XFree86 code is broken because it causes ALL keyboards (not just mine) to emit the same keycode - it just so happens that there is normally nothing in the keymap that coincides with that code. And this has nothing to do with the normal ALT-Fn switching of console screens - I cannot understand why you thought you needed to explain something there. I suggest you read what I said carefully. But I'll repeat because you don't seem to be listening. THE LOW LEVEL I/O POST ACCESS THAT XFREE86 USES WHEN TYPEMATIC IOCTL FAILS CAUSES ALL KEYBOARDS TO GENERATE A SPURIOUS KEYCODE. |