Re: [gentoo-user] EMERGENCY: X11 KEYBOARD MAPPING STOPPED WORKING!!!!
On Wed, 5 Jul 2023 16:42:15 -0400 Alan Grimes wrote: > I need a way to get X11 to boot into dvorak layout mode without having > to look up this e-mail to find the command to set the layout to dvorak. > > My current xorg.conf has: but does not do anything useful. > > Section "InputDevice" > # generated from default > Identifier "Keyboard0" > Driver "keyboard" > Option "XkbLayout" "us" > Option "XkbVariant" "dvorak" > EndSection > > > Michael wrote: > > setxkbmap -layout us -variant dvorak > I have this in my config file: Section "InputClass" Identifier "Keyboard" Driver "libinput" MatchIsKeyboard "on" Option "xkbmodel" "evdev" Option "xkblayout" "us" Option "xkbvariant" "altgr-intl" Option "xkbrules" "evdev" Option "xkboptions" "nodeadkeys" EndSection Maybe it helps.
Re: [gentoo-user] EMERGENCY: X11 KEYBOARD MAPPING STOPPED WORKING!!!!
On Wed, 5 Jul 2023 16:42:15 -0400 Alan Grimes wrote: > I need a way to get X11 to boot into dvorak layout mode without > having to look up this e-mail to find the command to set the layout > to dvorak. > > My current xorg.conf has: but does not do anything useful. > > Section "InputDevice" > # generated from default > Identifier "Keyboard0" > Driver "keyboard" > Option "XkbLayout" "us" > Option "XkbVariant" "dvorak" > EndSection > > > Michael wrote: > > setxkbmap -layout us -variant dvorak > Part of why I stepped away from the Dvorak layout. US layout would always, "just work". Like there were times when I'd have to type something when it was interpreted as US layout... But... Would putting that command in your ~/.xinitirc or some equivalent work? It kind of would be nice if it could be done in the xorg.conf I do agree. pgpKmg8cgYjEv.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Plasma session saving
It could also indicate a problem with the power supply failing. I've seen this a number of times and it often manifest as memory errors when testing the ram. Any number of things in the computer can fail in ways that may not be so obvious. Substitution trouble shooting may be needed, i.e. try a known good power supply with known good memory, or take half the ram out to see if the problem persist, then check the other half of the ram. It'd also a good also worth pulling and reseating the ram and any cards in it. I've got a big huger server that was having issues, it has a removable drawer for the cpu/memory, I pulled it out about 1/2 inch and reseated it and the errors stopped. That was a couple of months ago. Also probably a good idea to reseat the cpu as well. Finally, you should also check the fans/dustiness of the computer in question, both of which can produce higher temps and random behavior. And yes, it's a pain to properly test large amounts of ram, especially if you don't have a backup machine to work on while the other is testing. --"Fascism begins the moment a ruling class, fearing the people may use their political democracy to gain economic democracy, begins to destroy political democracy in order to retain its power of exploitation and special privilege." Tommy Douglas Jul 5, 2023, 11:50 by grant.b.edwa...@gmail.com: > On 2023-07-05, Peter Humphrey wrote: > >> This version of memtest86 ran to completion after going through the whole >> 64GB, and stopped with a success message. >> > > That's a pretty good sign, but I have seen memory that made it through > one complete test pass and failed on subsequent ones. > >> Over the last...oh, many months, I've noticed an occasional package in a >> large >> batch failing for no obvious reason, only to succeed on its own. >> > > What sort of failure? I've found that inconsistent/random gcc > internal errors or gcc segfaults have usually been due to failing > RAM. [Though in one case I remember, it was due to a failing SCSI disc > controller card -- back when that was a thing.] > > It might also be due to a failing disk, but there are usually good > indications of that in dmesg output and in SMART logs before it starts > to affect other things. > > -- > Grant >
Re: [gentoo-user] EMERGENCY: X11 KEYBOARD MAPPING STOPPED WORKING!!!!
I need a way to get X11 to boot into dvorak layout mode without having to look up this e-mail to find the command to set the layout to dvorak. My current xorg.conf has: but does not do anything useful. Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "keyboard" Option "XkbLayout" "us" Option "XkbVariant" "dvorak" EndSection Michael wrote: setxkbmap -layout us -variant dvorak -- Beware of Zombies. =O #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights.
[gentoo-user] Re: Plasma session saving
On 2023-07-05, Peter Humphrey wrote: > This version of memtest86 ran to completion after going through the whole > 64GB, and stopped with a success message. That's a pretty good sign, but I have seen memory that made it through one complete test pass and failed on subsequent ones. > Over the last...oh, many months, I've noticed an occasional package in a > large > batch failing for no obvious reason, only to succeed on its own. What sort of failure? I've found that inconsistent/random gcc internal errors or gcc segfaults have usually been due to failing RAM. [Though in one case I remember, it was due to a failing SCSI disc controller card -- back when that was a thing.] It might also be due to a failing disk, but there are usually good indications of that in dmesg output and in SMART logs before it starts to affect other things. -- Grant
Re: [gentoo-user] Plasma session saving
On Wednesday, 5 July 2023 16:38:35 BST Michael wrote: > Hmm ... you won't like what I have to say now about bad RAM: :) > Servers and specialised workstations with large amounts of RAM use RDIMM ECC > to correct errors. With modern PCs having even more RAM than some servers, > it can take forever to test them thoroughly using memtest86+. Perhaps if > you remove all but one stick and test it overnight, then replace this with > the next stick and so on until all are tested, you may find the problematic > stick sooner. This version of memtest86 ran to completion after going through the whole 64GB, and stopped with a success message. > Or, carry on as you are and keep an eye out for errors. A heavy round of > emerge can be as likely to come across it sooner or later. Over the last...oh, many months, I've noticed an occasional package in a large batch failing for no obvious reason, only to succeed on its own. I haven't been able to diagnose this, but it's one factor behind my trying to find the best settings of jobs and load average, on the suspicion that job control is weaker at high loads. > The other culprit to consider is a power supply problem, especially if this > is not a laptop or a PC fed off a UPS. A transient glitch could cause an > one off error and you wouldn't even notice it. I do run a UPS. Just as well, too, as the village is fed over-ground and we get one or two brief blackouts every year. They're odd, because they last longer than delayed auto-reclose but shorter than I would expect manual switching to take (I used to work in that industry). Maybe the operators are quicker on their feet these days - it was a long time ago. ;-) -- Regards, Peter.
Re: [gentoo-user] Plasma session saving
On Wednesday, 5 July 2023 16:23:01 BST Peter Humphrey wrote: > On Wednesday, 5 July 2023 15:05:28 BST Michael wrote: > > Did you try to reseat your graphics card and your RAM sticks, just in case > > their electrical contacts got oxidised? > > Not yet. I was hoping to avoid that because of difficulty of access. Hmm ... you won't like what I have to say now about bad RAM: Servers and specialised workstations with large amounts of RAM use RDIMM ECC to correct errors. With modern PCs having even more RAM than some servers, it can take forever to test them thoroughly using memtest86+. Perhaps if you remove all but one stick and test it overnight, then replace this with the next stick and so on until all are tested, you may find the problematic stick sooner. Or, carry on as you are and keep an eye out for errors. A heavy round of emerge can be as likely to come across it sooner or later. The other culprit to consider is a power supply problem, especially if this is not a laptop or a PC fed off a UPS. A transient glitch could cause an one off error and you wouldn't even notice it. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma session saving
On Wednesday, 5 July 2023 15:05:28 BST Michael wrote: > Did you try to reseat your graphics card and your RAM sticks, just in case > their electrical contacts got oxidised? Not yet. I was hoping to avoid that because of difficulty of access. -- Regards, Peter.
Re: [gentoo-user] Plasma session saving
On 7/5/23 10:05, Michael wrote: On Wednesday, 5 July 2023 14:07:36 BST Peter Humphrey wrote: On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote: On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote: [snip] Same problem as before, but now the three instances of gkrellm shimmer around their edges unless I move them away from the screen corners. I suppose this is an artefact of GTK2 and its ageing. I noticed the same flicker with the GKrellms window border, when I run an app which uses graphics hardware acceleration. Rolling over to another virtual desktop and back stops this gkrellm window border flicker. I'm using Plasma on Wayland, so I wasn't sure what the cause of this is: code rot in GKrellms, buggy Wayland, or my ancient graphics hardware. :-/ I've also noticed this with gkrellm on Plasma, but only on Wayland, not on xorg. I haven't paid any specific attention to the circumstances.
Re: [gentoo-user] Plasma session saving
On Wednesday, 5 July 2023 14:07:36 BST Peter Humphrey wrote: > On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote: > > On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote: > > > If this is the thing I've run into a few times over the years then the > > > only > > > way out I've found is to delete my user config files and start over. > > > > > > As a test, create a new user, log in using KDE and see if that user > > > saves state the way your account used to. If it does then Google > > > for the files you need to get rid of and treat your account like a new > > > user. > > > > > > HTH, > > > > Well, I'm sure it would have (helped), but I'd just done that, as well as > > installing a new system from stage-3. It's on the new system that this is > > happening. > > Meanwhile, I got a hardware exception, apparently relating the the system > RAM, so I ran a recent version of memtest86 overnight and found nothing > wrong. Time to start again with a new installation and a new user. > > Same problem as before, but now the three instances of gkrellm shimmer > around their edges unless I move them away from the screen corners. I > suppose this is an artefact of GTK2 and its ageing. I noticed the same flicker with the GKrellms window border, when I run an app which uses graphics hardware acceleration. Rolling over to another virtual desktop and back stops this gkrellm window border flicker. I'm using Plasma on Wayland, so I wasn't sure what the cause of this is: code rot in GKrellms, buggy Wayland, or my ancient graphics hardware. :-/ > Moreover, the two latest versions of Firefox do not show as they should. > There's no upper frame, the min/max/stop buttons appearing in the tab bar > instead - in the wrong decoration style: I have the Plastik scheme set, but > the buttons are shown in something similar to the Breeze scheme. And middle- > click and right-click on the maximise button have no effect. > > I can't find anything here to explain my problems, so I've raised https:// > bugs.kde.org/show_bug.cgi?id=471977 Did you try to reseat your graphics card and your RAM sticks, just in case their electrical contacts got oxidised? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma session saving
On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote: > On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote: > > If this is the thing I've run into a few times over the years then the > > only > > way out I've found is to delete my user config files and start over. > > > > As a test, create a new user, log in using KDE and see if that user > > saves state the way your account used to. If it does then Google > > for the files you need to get rid of and treat your account like a new > > user. > > > > HTH, > > Well, I'm sure it would have (helped), but I'd just done that, as well as > installing a new system from stage-3. It's on the new system that this is > happening. Meanwhile, I got a hardware exception, apparently relating the the system RAM, so I ran a recent version of memtest86 overnight and found nothing wrong. Time to start again with a new installation and a new user. Same problem as before, but now the three instances of gkrellm shimmer around their edges unless I move them away from the screen corners. I suppose this is an artefact of GTK2 and its ageing. Moreover, the two latest versions of Firefox do not show as they should. There's no upper frame, the min/max/stop buttons appearing in the tab bar instead - in the wrong decoration style: I have the Plastik scheme set, but the buttons are shown in something similar to the Breeze scheme. And middle- click and right-click on the maximise button have no effect. I can't find anything here to explain my problems, so I've raised https:// bugs.kde.org/show_bug.cgi?id=471977 -- Regards, Peter.
