Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
For convenience, I have added the french ligature characters Œ and œ to my German „~/.xmodmap.de”. Activating these key-mappings with a call to xmodmap stresses my CPU to the point that some activities are almost, others downright impossible for a few minutes.
Also, adding the call to xmodmap to my Fluxbox startup-file does nothing. I have to assume that xmodmap is not at all executed until I do it manually. Afterwards all is fine and the desired key-mappings are available.
This behavior is observed since I know about xmodmap, a time which spans several Debian-releases and at least one similar experience on Mint.
Does someone have an explanation?
TIA
Last edited by Michael Uplawski; 06-01-2016 at 02:45 AM.
That sounds really weird. I would think (not knowing the internals at all) that xmodmap just has to update a few tables, etc.. Why would it need more than a few milliseconds to do anything?
I have no idea what the real issue is.
I have never used it, but I have seen people use strace for problems like this. It tells you what a program is actually doing. The issues are getting it to invoke for the proper program instance and then knowing enough to interpret the results (which is why I don't use it )
You might also want to try your setup on a different distro with the same version of xmodmap (with a VM or live CD) to see if some other factors are at work.
As for your startup issues:
I fool around with autostart stuff in KDE. Since the autostart activity occurs when normal i/o is not connected to a terminal/display, you can't see what is happening when something doesn't work. To get around this, I modify the autostart script so that commands and added echo statements redirect their output to a file. Then I have a log file so I can see what happened and debug it after the desktop finishes loading.
Example code:
Code:
log="~/temp/autostart.log"
echo "$(date) Starting autostart" > "${log}" ## clear old log
some-command &> >> "${log}" ## append any output from command to my log
rc=$?
echo "$(date) some command returned with [${rc}]" >> "${log}" ## and append its return status
If it takes more than a try or two to fix things, I add a debug variable so I can switch the log on and off by testing it before any line that logs something. The sleep is there because the things I am looking for don't always happen right away, so I wait a little bit before looking for them.
Code:
debug=0 ## turn off debuging output
debug=1 ## turn on debuging output
sleep 5 ## give kde some time to get started
((debug)) && echo "$(date) autostarting applications" > "${log}" ## debug
Last edited by josephj; 06-01-2016 at 04:18 PM.
Reason: typo
@Emerson: Thank you. I have read about ~/.Xmodmap (or ~/.xmodmap). I will link my German mapping file to ~/.Xmodmap to try it out.
@josephj: Good hints, all. This morning I would like to follow all your advice at once, and just post my results here. But I have not yet the time for testing. I'll get back to that in another post.
The existence of a file ~/.xmodmap or ~/.Xmodmap does not have an influence. Anyway, having entered other commands in the fluxbox startup file, xmodmap is still the only one which is ignored, even if I note a specific mapping-file for the argument.
Calling strace with xmodmap ~/.xmodmap.de I get a log on standard output. The execution takes just a moment. Like without strace, the program appears to return immediately, although the CPU continues to struggle for a few minutes. This said, the log file is not long enough to cover any of this obscure activity as it is created and terminated before. However, there is only one repeated line in the strace output, which looks curious.
For recvmsg, the resource must be a socket and it would be interesting to know which socket is currently blocked by another process. The output is the same, if I call strace as root. I venture that, without knowing the socket or process, calling lsof will not help me find the culprit, if there is any.
But as I said, strace returns quickly and the CPU continues anyway to be occupied. Many functions are unavailable for some minutes.
Last edited by Michael Uplawski; 06-02-2016 at 07:45 AM.
Reason: too many words. ( I )
If it's Xorg itself chewing up the CPU cyles, perhaps there is some circular reference in it's modmaps as soon as you add those entries. Can you post the offending file contents, and the output of `xmodmap -pk`?
Also, what do you get (before you merge ~/.xmodmap.de) with xmodmap -n ~/.xmodmap.de. It should tell you what it would do, without actually doing it.
I have, in the past, completely borked my X session with a bad xmodmap merge. Also, Xorg gets confused when you play around with xmodmap too much. I found that restarting X constantly while you play with your new settings is useful. It may behave differently when it's fresh versus after many xmodmap alterations.
@mdooligan: Xorg is in deed misbehaving after an apparently successful execution of xmodmap. Ctrl-Alt-Backspace does no longer work and Alt-tab does not switch between windows. Anyway, here are all those weird keymaps and program-outputs that you asked for. I have to attach this as files, as the posting becomes too long, otherwise.
1. The file ~/.xmodmap.de (xmodmap.de.txt). Keycode 32 is modified for Œ and œ.
2. The output of xmodmap -pk after execution of xmodmap ~/.xmodmap.de (pk_out.txt).
3. The output of xmodmap -n in a clean Xorg session with original, unchanged key mappings (n_out.txt).
Last edited by Michael Uplawski; 06-02-2016 at 02:06 PM.
Reason: punctuation.
I do not want to download these files, but I can tell by their size you can do better. Do not load the whole thing again. I have ~/.Xmodmap in home computer and it has less than 10 lines in it. Just adding some symbols I need to default keymap.
OK, at home now. I let system load default keymap and add only some symbols I need, see below:
Code:
~ $ cat .Xmodmap
keycode 133 = Mode_switch
keycode 13 = 4 dollar 4 cent
keycode 24 = q Q otilde Otilde
keycode 26 = e E EuroSign cent
keycode 30 = u U udiaeresis Udiaeresis
keycode 32 = o O odiaeresis Odiaeresis
keycode 38 = a A adiaeresis Adiaeresis
keycode 40 = d D degree
keycode 58 = m M Greek_mu
With only two lines remaining, the mapping file does exactly what I need, xmodmap returns immediately and nothing is left of the CPU trouble. This did not bug me enough to ask earlier, but I should have done so!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.