Hi,
I'm using XBMC 9.04.1 on Slackware 13.0 (32-bit) and KDE 4.2.3.
Every time I press the Right Ctrl key the screen capture dialog box appears. Pressing the Print Screen key does not replicate the action. How do I correct the key mapping so the dialog box appears when pressing the Print Screen key rather than the Right Ctrl key?
I use a Northgate OmniKey Ultra keyboard. I never have experienced any problem like this.
Thanks.
Both keys are set for screenshot. RightCtrl for keyboards w/ reduced keys obv.
Okay, thanks for the info. How do I unmap Right Ctrl?
I depend way too much on the Right Ctrl key for normal typing and usage to try to merely avoid the new mapping.
I am browsing and searching the wiki but have not yet found the answer.
I have found a <printscreen> keymap function but not a <rightctl> or anything similar.
You don't, it's hard coded AFAIK.
Um, nowhere in XBMC do we hardcode RightCtrl for anything AFAIK. At least we don't do it on purpose!
Quote:<rightctrl>-</rightctrl>
Hmm. No effect.
Quote:You don't, it's hard coded AFAIK.
Where in the sources? I'll recompile if I know where to edit and create a diff patch. Being hard-coded is just too disruptive. Thanks.
Quote:Um, nowhere in XBMC do we hardcode RightCtrl for anything AFAIK. At least we don't do it on purpose!
Okay, then why is this happening? I never have seen such behavior in 30 years of using computers.
Can you find <rightctrl> within XBMC/system/Keymap.xml?
I've dropped the extraneous mappings in r22914.
Quote:Can you find <rightctrl> within XBMC/system/Keymap.xml?
Nope.
Quote:I've dropped the extraneous mappings in r22914.
What does that mean? Was RightCtrl being mapped the same as Print Screen? How do I do the same from 9.04.1?
Running showkey and xev reveals the two key presses (Right Ctrl and Print Screen) are different. So something else within XBMC is picking up the Right Ctrl key press on my system.
woodsman Wrote:So something else within XBMC is picking up the Right Ctrl key press on my system.
This is probably an accurate deduction as he said above it was addressed in the SVN. Most people use a remote to use XBMC so probably no one mentioned it til you posted here on the forums. If you update to that SVN mentioned the problem should be addressed without you having to do any work.
For XBMC development, are SVN versions considered testing versions only (buggy), or considered rather stable?
woodsman Wrote:For XBMC development, are SVN versions considered testing versions only (buggy), or considered rather stable?
It depends on what's going on with the development, it's fluctuates. 22528 Is relatively the most stable recent build. They're making some big changes in SVN right now. Though althekiller says he's addressed the issue in 22914 which probably means that version is at least usable. Whether it works for you is yet to be determined.
If you compile your own you can use SVN to specify which revision to grab.
Thank you. Is there a way to learn which SVN versions are more stable than others? Is there a forum thread appropriate to learning such information or asking such questions?
I'm very new to XBMC. Still getting my feet wet.
woodsman Wrote:Thank you. Is there a way to learn which SVN versions are more stable than others? Is there a forum thread appropriate to learning such information or asking such questions?
I'm very new to XBMC. Still getting my feet wet.
Probably not, SVN changes numerous times a day most of the time. Probably the best bet is coming into the IRC channel and chatting with the devs about it. Though I'm not sure how they feel about it. For right now there is an announcement on the homepage:
http://xbmc.org that says so and they've said that when the changes in SVN settle they'll post another on the front page to announce when it's stable enough and they're looking for bug reports again.