kde-4.5.5: partially lost fn keys on a wireless keyboard, right click only works on workspace 1

[gene heskett]

On Sunday, January 23, 2011 08:27:28 am Duncan did opine:

Wow, a veritable encyclopedia of things to check here Duncan and I have 
printed it so I can go down it, checkmarking  as I go.  Thank you very for 
taking the time to write this.

> gene heskett posted on Sat, 22 Jan 2011 16:08:48 -0500 as excerpted:
> > 2 questions actually...
> > 
> > I am an incurable fan of mc for a file manager.
> 
> So am I! =:^)
> 
> > However it appears
> > recent updates to kde, now at 4.5.5, seem to have installed some key
> > gobblers and the only Fn key that works in mc is the F10=quit key. 
> > All of the others I have been reduced to using the mouse for, and I
> > have a similar complaint when trying to control some of my home
> > brewed scripts with htop, which can use a mouse but is extremely slow
> > at recognizing a mouse click on the kill=F9 buttun.
> 
> FWIW I skipped the 4.5.5 update as I'm on Gentoo and updating would have
> meant building it.  I decided 4.6.0 was only a couple weeks away, 4.5.4
> was working fine, and none of the fixes in the changelog for 4.5.5
> looked worthwhile enough to bother with that update, so I stayed on
> 4.5.4 until 4.6.0 is released, scheduled for later this week (Jan 26,
> my B-day as it happens! =:^)
> 
> However, I've not had any such problems here and believe me, if I had
> have had them I'd have been crying bloody murder and reverting back to
> an older, working version, for sure, because as I said, I'm a heavy mc
> user here, too!
> 
> > The configure (drakethis and drakethat) menu's do not appear to
> > address this specific issue.  32 bit pclos-2010 install on a quad
> > core phenom, kernel 2.6.37.
> 
> FWIW, the drake* apps are distribution-family (from mandrake, now
> mandriva) specific.

And pclos is somewhat based on mandriva.

> The kde config method is using kcontrol, aka
> system settings (which is so hopelessly generically labeled as to be
> nearly worthless, not to mention that it's hardly accurate since most
> of the settings as kde ships it are kde specific and user specific
> anyway, *NOT* system settings, but that's what they renamed it to for
> kde4, tho the kde3 kcontrol remains more accurate).
> 
> So I'd suggest looking around in kcontrol aka system settings for kde
> config, as that's what people here will know.  For the drake* stuff,
> you'd post to your distribution's mailing lists, since that's what
> they'd know.

Pclos does everything via a forum, with IMO about 4x the categories needed, 
so you post where you think you may find an expert.  If you don't guess 
right, too bad. I much prefer mailing lists.

> > Where should I go looking to be able to negate this unwanted Fn key
> > gobbling for the first 9 keys?
> 
> You're running mc (and presumably htop as well) from a terminal window,
> presumably konsole, correct?

yup

> There's several levels at which things
> might be screwed and you can try to address this.  As I've not
> experienced the issue here, I can't say which one is triggering your
> problem, so you'll probably have to experiment a bit with all of them
> until you get things working correctly again.
> 
> 0) Before you start, it's a good idea to see if the problem is in your
> user config or in the system-global config.  Try setting up a new user
> (or when kde isn't running, rename your ~/.kde or other user-specific
> kde settings dir), then launch kde with the blank kde config and see if
> the problem persists.

That will be the first thing I'll try.
 
> It's also worth checking for sure that it's not a hardware issue. 
> There's an X diagnostics app called xev (short for X-event) that, when
> run from konsole (or another terminal window app), will popup a window.
>  Moving your mouse around and/or hitting either mouse or keyboard
> buttons will cause it to report the triggered events on its stdout --
> the terminal window.  Try hitting your function keys and ensure they're
> reported /as/ function keys, not function-control (stuck control key),
> not unrecognized, etc.  It shouldn't be difficult to get the hang of
> using xev for this sort of diagnostics, altho moving the mouse causes a
> **LOT** of events, that will quickly scroll anything else out of the
> terminal window.

It appears the keyboard is good, all the function keys are properly 
reported.

> Finally, consider installing and trying another terminal window app,
> xterm or gterm (if you have gnome installed) or something.  If mc works
> fine in it, still running under kde, pay particular attention to #2
> below as it would appear to be your konsole config at fault.

One potential clue I might add to this recipe for disaster is that I write 
bash scripts to help me automate things.  Much of this trouble stated when 
I started to make use of the inotify-tools packages utility "inotifywait"

This utility needs filters for legit hits on its output, but also needs 
absolute, never forget it, redirection of its output on startup in the 
usual 2>&1 >/dev/null style within the script, and the script itself given 
the same treatment, else the terminal it was launched from seems to be 
getting invisible commands that result in fouled up color selections, 
needing to hit the enter key twice and other such WTF's?

> The below assumes that it's either a user issue or that at least you can
> adjust the user config to fix the problem, if it's a global issue.
> 
> 1) Application level.  In mc's options menu, select Learn keys...  At
> minimum you can use this for diagnostics, to see which keys it actually
> detects.  If worse comes to worse and it's not detecting certain keys
> you use a lot, you can try remapping them, here, as well.  But that's
> likely to be difficult if it's not seeing the function keys at all, as
> there's simply not enough other easily remembered combinations that
> aren't already used for something else.  But as I said, at least you
> can use it to see what's detected, running this after changing settings
> elsewhere, to see if it detects them properly, again.

mc is seeing the function keys, on its command line as esc sequences.
 
> 2) Terminal window level.  Again, I'm presuming you're using konsole. 
> If you use a different terminal window app, see what sort of
> configuration it might have.  Meanwhile, I suspect this is actually
> where your problem is.

So do I.
 
> In konsole, select settings, configure profiles.  Then select the
> appropriate profile and hit the edit profile button.  In the resulting
> edit profile dialog, switch to the input tab.  I'm guessing this is
> what's screwed up altho as I said I'm not sure since I haven't seen the
> problem here.

I'll try that too.
 
> FWIW, I haven't actually screwed with this much, as I've not needed to.
> Hopefully, you can fix the problem by simply selecting a different set
> of keybindings.  FWIW, here, I have the Default, (XFree 4), keybindings
> selected.

I don't recall what I am set for there, but will check.

> If I hit edit and move down to the function+anymodifier
> section, here's what it looks like:
> 
> F1+AnyModifier		\EO*P
> F1-AnyModifier		\EOP
> F10+			\E[21;*~
> F10-			\E[21~
> F11+/-			(as F10 but 23 instead of 21)
> F12			(as F10 but 24)
> F2			(as F1 but Q instead of P)
> F3			(as F1 but R)
> F4			(as F1 but S)
> F5			(as F10 but 15)
> F6			(as F10 but 17)
> F7			(as F10 but 18)
> F8			(as F10 but 19)
> F9			(as F10 but 20)
> 
> There's a test area that you can use, too, if you need to modify any of
> these.  As I said, I think/am-hoping this is all that's messed up, and
> if you're lucky, all you have to do is switch keybindings profile,
> here, without even editing any of them.  As mentioned above, you can go
> into mc and test to see what it's recognizing, if you switch something
> around here.
> 
> 3) KDE global hotkeys level.  Here's where kcontrol aka system settings
> comes into play.  Under common appearance and behavior, shortcuts and
> gestures, check all three applets and see if any of them are set to
> function keys that might be robbing them from mc.  This bit I've
> customized somewhat, so it just might be that I've not seen the problem
> due to my customizations overriding something else.  But it doesn't seem
> sane to me that they'd setup unmodified function-key shortcuts by
> default, for precisely the reason you're seeing -- they're too likely
> to conflict with another app that uses them.  So I really doubt it's
> this level, unless something got really screwed up somewhere.
> 
> My bet is still on #2, because I do remember having issues with that a
> long time ago, back on kde3, at one point.  All I remember is fiddling
> with the konsole keybinding profiles and trying mc's learn-keys thing,
> until I got it sort of working again.  But I think I might have been the
> one that messed it up for myself that time, fiddling with konsole's
> keybindings in the first place.  Which is why I've not touched it since.
> As long as it works, I'm not going to bother that bit.
> 
> > Secondarily, since the last update, I only have a right click menu for
> > desktop settings on the first workspace.  No reaction to a right click
> > on any other workspace, which of course are black, no background pix.
> > 
> > How can this be fixed?
> 
> The mouse button on desktop actions are configurable now, per desktop.
> Click on the toolbox (aka cashew) for each desktop and select desktop
> settings.  In the resulting dialog, select mouse actions on the left,
> and then setup the actions you want.  You can set separate actions for
> left/ middle/right and scroller triggers, with modifiers
> (ctrl/alt/meta/shift) as well if desired, so there's quite a few mouse
> actions available to assign stuff to, if desired.  The "standard menu"
> action is the traditional context menu, so that's what you'll probably
> want to assign to the (unmodified) right button.  AFAIK that's
> /supposed/ to be the default, but with 4.5, there's a bug and the
> default only gets assigned to the first one.  You have to assign it to
> the others yourself.  With 4.6 hopefully that bug is fixed, tho I
> hope/expect that it'll leave the setting alone if someone's already
> customized it.

Thank you very much Duncan, I have a checklist now.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
In my end is my beginning.
		-- Mary Stuart, Queen of Scots
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.