Wireless Devices are Disconnected When Running Odilia

[mcb2003]

When Odilia is started, both my wifi adapter and my bluetooth adapter get disconnected from any devices / networks they're connected to.

As of yet, I'm unsure of why this is, although I'm thinking it might be related to #19.

[albertotirla]

it could be related, true, however that spike only affects one core, not everything else, otherwise not only wireless would be affected. Your entire system would slow to a crol, you wouldn't be able to stop odilia even, everything would kinda lock up if all the cores were affected. My hypothesis is that the evdev grabbing we do grabs more than expected, which means the mouse, wireless, everything ends up being owned by odilia, but since odilia doesn't listen for those events, eventually the wireless connections end up being dropped because of them being held two long without anything read from them, so the kernel closes them. To verify this, I recommend you comment out the line where the input monitoring task is being launched. If the problem disappears, then we know my theory is right and we can proceed with trying to find a fix. I only hope the input daemon approach isn't going to perform the same capturing of anything and everything.

[TTWNO]

Not reproducible. Can you send a dmesg ,log of this happening. @mcb2003

[albertotirla]

it's reproduceable only in cases when the wireless device in question is also advertising to be a keyboard or something like that. For example, some bluetooth headphones have mute buttons, volume up/volume down, which don't affect the headphones, rather the computer itself. How that's done, well, the headphones, besides the audio/handsfree profiles they allready register, they also register the keyboard profile, so that when those buttons are pressed, they will send actual keycodes corresponding to the action, yes, we have keycodes for media keys, surprised, no, good. So then, it's entirely possible that the kernel presents the keyboard profile, or maybe the entire thing, as a keyboard evdev device, which is exactly what odilia listens for and captures. Since the capture is done in a keyboard device, not bluetooth fassion, the headphones will simply stop getting bluetooth signal, in which case the connection will time out from their perspective, forcing them to enter pairing mode, power down, depending on headphones. I think that's the most logical explanation for this phenomenon, the solution for now is to just not use those headphones while odilia is running, longterm this won't be a problem at all, since after we devise a solution for wayland, we won't be using evdev anymore and the higher levels of the stack will better distinguish between real keyboards and something else masquerading as a keyboard, possibly eliminating devices which don't have enough keys or whatever, but that detail is stack specific and won't concern us in the future.

[TTWNO]

Hi, @mcb2003 can you confirm this is still happening with the latest build, since we solved the problem you thought it was related to?

It may be that the sohkd code is scanning for all I/O devices to find the keyboard, and that is causing this behavior. If this is the case, I'd be happy to submit an upstream issue, but some input from you would be nice since since you were the one who originally posted it.

[mcb2003]

Hi, @mcb2003 can you confirm this is still happening with the latest build, since we solved the problem you thought it was related to?

I checked a couple of weeks ago and it appears to be fixed, yes.

It may be that the sohkd code is scanning for all I/O devices to find the keyboard, and that is causing this behavior. If this is the case, I'd be happy to submit an upstream issue, but some input from you would be nice since since you were the one who originally posted it.

I can't 100% confirm this isn't the issue, but I highly doubt it now that it seems to be fixed. Besides, scanning those devices, particularly if we're not swallowing any key presses, shouldn't be a problem (we're not modifying the events). Also, I'd be very surprised if a wireless chipset required use of a virtual HID device to be used. Even if that were the case and we were swallowing those events, all that should affect is the wifi / bluetooth toggle key that some laptops (mine included) have.

I'm closing this for now as it seems to be fixed. If the issues reappear, I'll let you all know.