Login at Kodi Home

mikaelj · (This post was last modified: 2014-09-04, 13:04 by wsnipex.)

From the original bug at http://trac.xbmc.org/ticket/14028: XBMC forgets my bluetooth keyboard(s) after they wake up again.

My added comment to the ticket:
----------------
This still happens and it is /not/ operating-system related.

* System: x86
* OS: Ubuntu 13.04 /and/ Ubuntu 14.10
* XBMC: 13.xx to 14.xx.
* Input devices: Logitech Mediakeyboard Pro; Satechi BT MediaRemote.

On the Logitech Media Keyboard Pro with integrated touch pad, the /mouse/ continues to work, but not the keyboard in /XBMC/. In the operating system, the keyboard works as expected. Same problem with a Satechi BT MediaRemote, which only offers keyboard thus not working at all.

Sometimes, the keyboard won't even work at XBMC startup. Sometimes, it'll work after waking up. It is, in any event, an /XBMC/ bug.

Please re-open. If there are any logs you need, let me know.
----------------

Any suggestions on what I can try out?

RELATED POSTS:
* http://www.reddit.com/r/xbmc/comments/2c..._a_random/

fbacher · 2014-08-29, 20:06

I have been seeing the same or similar problem for a few months. The keyboard input just stops working at "random" times. I have not investigated yet.

mikaelj · 2014-08-30, 13:02

That's interesting. Most bugs are attributed to bad hardware (unpowered USB hubs or Bluetooth stacks), but it is indeed a problem in XBMC itself.

Any suggestions on where I would go about debugging it myself the best? I guess it all happens in https://github.com/xbmc/xbmc/blob/master...evices.cpp but I haven't tried making my own build printf()s sprinkled around.

Wish any of the XBMC developers would read it.

mikaelj · 2014-09-04, 10:08

Bump. Anyone?

FernetMenta · 2014-09-04, 10:25

On Linux systems with X11, i.e. Ubuntu, XBMC gets keyboard input from the X-Server if the application is focused. If we don't get anything, XBMC is either not focused or the X Server does not send anything. (Only looking at Helix version)

mikaelj · (This post was last modified: 2014-09-04, 10:35 by mikaelj.)

Thank you, that is a good explanation. I know for a fact that the X server sends keyboard (and mouse) data.

What I'm currently seeing is this behaviour:
1. Start XBMC
2. Use keyboard in the UI to go to Video -> Files -> open a video
3. Keyboard /usually/ stops working in video mode
4. Exit video with mouse
5. Keyboard doesn't work in UI.

So: for some reason, the video window, when created, isn't focused, and when exiting, the UI window isn't focused either.

Somewhere between "Create New Window" and "Display Window", keyboard focus is lost.

Is the UI window hidden (= temporarily giving focus to another window/application) just before opening up the video playback window?
Since it doesn't happen every time, it sounds like a timing issue.

FernetMenta · 2014-09-04, 11:07

Please consider that I do only talk about Helix version because Gotham uses outdated and faulty SDL.

When XBMC/Kodi is fullscreen it gets keyboard input when the mouse is in the region of the window. This is standard X11 behavior. So if you see the mouse pointer on the XBMC window and you don't get any keyboard input, something outside XBMC is wrong.

mikaelj · (This post was last modified: 2014-09-04, 11:09 by mikaelj.)

Oh, then I should update to Helix to see if that fixes my problems first. Good, thanks!

------------------------------------------------
(posted the text below before I saw your reply above)

Looking at the source of xbmc/master, call chain is as follows:

void CGUIWindowManager::ActivateWindow_Internal(int iWindowID, const vector<string>& params, bool swappingWindows)
->
void CGUIWindow::OnInitWindow()
->
?

I *think* a resolution change happens when I go from browser to video playback, because my TV displays the name of the input.

Then at some point, I'm guessing the calls trickle down to CWinSystemX11::SetFullScreen(...) which doesn't properly set focus to the newly created(?) fullscreen window.

**wsnipex** · 2014-09-04, 11:52

on Gotham, you are hitting a know SDL bug which causes loss of input in xbmc on refresh rate change.
ugly workaround: disable "adjust display to match video refresh rate"

proper solution: use a helix nightly.

mikaelj · 2014-09-04, 11:55

(2014-09-04, 11:52)wsnipex Wrote: on Gotham, you are hitting a know SDL bug which causes loss of input in xbmc on refresh rate change.
ugly workaround: disable "adjust display to match video refresh rate"

Oh, no wonder then.

(2014-09-04, 11:52)wsnipex Wrote: proper solution: use a helix nightly.

That did indeed fix my problems! I'm happy again. (this thread can be closed by an admin)