http://bugzilla.suse.com/show_bug.cgi?id=994206 http://bugzilla.suse.com/show_bug.cgi?id=994206#c2 Benjamín Buske <benjamin.buske@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X11 3rd Party Driver |X.Org --- Comment #2 from Benjamín Buske <benjamin.buske@gmail.com> --- (In reply to Egbert Eich from comment #1)
(In reply to Benjamín Buske from comment #0)
Hello,
I lately ran into the following issue:
When one of my programs froze, I wanted to switch to a virtual terminal in order to kill it from there. I noticed however, that the terminal would not open. Instead key combinations such as CTRL+ALT F1 and F2 would switch between desktops, etc. The issue remained, even after restoring the keyboard and shortcut settings to default and even after doing a clean re-install.
Did you keep your home-directory?
- On one machine I did, on the other I did not. However, the reason for the reinstall was not the terminals not working but a re-partitioning. The terminals and sleep worked fine on the first install.
The equipment is an HP Desktop with AMD on-board chipset.
Strange enough, on both systems the terminal works, if I switch from the log-in screen, when no session has been initiated.
This indicates that your session changes the xkb mappings.
That is exactly what I think as well. However, no changes have been made to the mapping of either machine. The other machine with the same issues, was a clean install, on an empty HDD.
Additionally, if I change sessions and return to the log-in this way, it does work fine as well. However, upon using CTRL+ALT+F7 to go back to my original session, the issue continues.
I don't understand what you're saying here.
I found a hint on the forums, from some years ago. Someone with a similar problem mentioned, that he could get to the terminals, when he was selecting "Start new Session" from the menu. The system would change to the login screen, to start a new session and the terminals work. They also do, as soon as a session is ended and you return to the login screen.
However, I use a second computer, a Desktop, as well, which is equipped with a Nvidia Chipset. The same problem. Later on I noticed, that the AMD Laptop in addition to the above did not wake up from sleep properly, but instead just showed a black screen.
This is a different problem. Report this in a separate ticket, supply logs (Xserver log and dmesg output).
I will do that shortly, once I am able to get access to the machine.
Posting my issues on the forums (https://forums.opensuse.org/showthread.php/519445-TTY-and-Power-Saving- Issue), I have soon received some replies and we did run some commands and tests, which have been all fine. So a recommendation was made, to download the proprietary fglrx drivers or - alternatively - boot the system with "nomodeset". Checking my packages, I noticed that the fglrx drivers have been there already and hence, thinking it might be them, I removed them. The system then booted up with the open source drivers, however the issue remained the same.
Which issue? You were talking about 2 issues.
The above thread was about both issues. The black screen after putting the computer asleep as well as the not working terminals both seemed to be graphic related. This seems to be confirmed by the fact, that the issues have been resolved by reinstalling the proprietary drivers and by proving that the original open-source drivers did not work.
Also: <quote>The system then booted up with the open source drivers,</quote>
- which drivers were these?
When in a next step, I booted up the system with "nomodeset", I received an error that no AMD UMS support was found, but the system worked fine other than that. However, I could not make changes to display brightness and many programs I need for work ran very slow due to missing driver support. Still,
Yes, this is to be expected as a fallback driver is used.
Completely fine with me. Since the system booted up fine I expected this to be the case. Still, I just wanted to point out every step and what has happened.
this time terminals and sleep mode worked just fine. Since the loss of the terminals and sleep mode is annoying, but the working programs - obviously - more important, I decided to reinstall the fglrx drivers once again.
After the reinstall, the system booted up fine and with no error. In addition terminals and sleep mode work just fine and without any issues. I have not yet made these changes to the other machine (it is my little daughters computer and neither goes to sleep nor does it really need terminals), but I am fairly sure the issue evolves from the open source drivers. I installed the fglrx drivers, the system simply kept using the open source ones, until I reinstalled.
Ok, so now everything works - therefore, I'm not sure how to proceed from here.
Again, which issue did you refer to by: <quote>I am fairly sure the issue evolves from the open source drivers</quote>?
The issue of the not working terminals and the black screen after waking the machine up from sleeping both seem to be an issue of the open-source drivers, as installing the third party drivers and / or using nomodeset both fixed the issue.
Is: <quote>I suppose that the first time, I installed the fglrx drivers, the system simply kept using the open source ones, until I reinstalled. </quote> an assumption or did you check logs?
Could it possibly be, that there is a configuration error or something? At least looking at the terminals, that would explain why the shortcuts reserved for the terminals are triggering other functions. It is not generally a bad idea to have keyboard shortcuts to switch desktops or see a summary of all open windows. It should just not affect the terminals but could possibly use higher F keys, after F7 or an entirely different sequence.
The sequences triggering a vt switch are no shortcuts but are keyboard actions performed by the Xserver. This is an important difference as shortcuts are interpreted by an application which has a grab on the some keys. Neither one are related to the driver used at all. The only thing I can envision is that a VT switch fails for a certain driver, however as you say it's working when you are on the login screen this is not all that likely. Still, we can only tell with logs from the Xserver.
-- You are receiving this mail because: You are on the CC list for the bug.