Mir-backed InputDeviceModel doesn’t work on touch device

Bug #1638517 reported by Olivier Tilloy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qtsystems-opensource-src (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

I’ve prepared a branch of webbrowser-app that makes use of the latest qml-module-qtsysteminfo for input device detection (https://code.launchpad.net/~osomon/webbrowser-app/use-qtsystems/+merge/309667), and when I test it on arale, I’m seeing the following error in the logs when connecting a bluetooth keyboard/mouse combo to the device:

QObject: Cannot create children for a parent that is in a different thread.
(Parent is QInputInfoManagerMir(0xaa09a6ac), parent's thread is QThread(0x1fba0b8), current thread is QThread(0xb08612d8)

This looks like a threading issue in the implementation of the Mir backend for InputInfo.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can reliably reproduce the issue with the following standalone example:

import QtQuick 2.4
import QtSystemInfo 5.5
Item {
  InputDeviceModel {
    filter: InputInfo.Keyboard
    onCountChanged: console.log("keyboard count:", count)
  }
}

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

I tested this in bug #1536669 on krillin and Unity 8 desktop on Chromebook, and it worked fine with the example apps, the QML of which called:

    InputDeviceModel {
        id: deviceModel
        filter: InputInfo.Keyboard | InputInfo.Mouse | InputInfo.TouchScreen
        onCountChanged: {
         console.log("new count of filtered devices: " + devices)
        }
    }

It doesn't say it there but I believe I did test with my Bluetooth mouse too. But maybe indeed there's some case either arale specific or related to the mouse+keyboard combo.

Changed in qtsystems-opensource-src (Ubuntu):
status: New → Confirmed
assignee: nobody → Lorn Potter (lorn-potter)
Revision history for this message
Lorn Potter (lorn-potter) wrote :

How can I reproduce this? When I try that qml on qmlscene on my lenovo yoga running unity8, I get a seg fault in libunubtu_application_api_desktop_mirclient.so.3.0.0

Changed in qtsystems-opensource-src (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Lorn Potter (lorn-potter) wrote :

where is the latest bzr repo?

Revision history for this message
Olivier Tilloy (osomon) wrote :

@Lorn: no need for webbrowser-app, the issue can be reliably reproduced with the standalone QML example in comment #1. I just tested on arale with the latest rc-proposed image, saved the example as /tmp/test.qml and ran it like so:

  phablet@ubuntu-phablet:/tmp$ qmlscene --desktop_file_hint=unity8 test.qml

When plugging in a bluetooth keyboard/mouse combo, I’m seeing the following output:

QObject: Cannot create children for a parent that is in a different thread.
(Parent is QInputInfoManagerMir(0xae10e6ac), parent's thread is QThread(0x1612170), current thread is QThread(0x176c3f8)
qml: keyboard count: 0

Revision history for this message
Lorn Potter (lorn-potter) wrote :

I meant latest repo for qtsystems-opensource-src.

Revision history for this message
Olivier Tilloy (osomon) wrote :

I don’t know where that code lives.
https://code.launchpad.net/ubuntu/+source/qtsystems-opensource-src/ doesn’t have the latest changes it seems. Timo would know.

Revision history for this message
Lorn Potter (lorn-potter) wrote :

I can reproduce this on turbo.
Does not happen when running the inputinfo console app in qtsystem examples.

Revision history for this message
Lorn Potter (lorn-potter) wrote :

Got this working on my laptop w/ unity8...
Except it does work, still see that thread message, except the count is opposite of what it should be.

When I disconnect the keyboard (usb as well as bt) it says count: 2, and when I connect it count: 1

When I first run the test qml, it reports count: 0
when it should report 1, as the laptop has a keyboard.
The first time I connect a keyboard there is no report, or when I first disconnect it.
Subsequent connection I see count: 1 (should be 2)
...

So it does seem to work regardless of the thread message, just not as it should.

Revision history for this message
Lorn Potter (lorn-potter) wrote :

@osomon The reason you are seeing this not work correctly, is because the value for countChanged signal is named 'devices' in the declarative class, and not 'count' like what is in the base class and that you are using in your qml example.

This should probably get changed in the declarative class to match the base class.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Nice catch Lorn! This is a nasty one. I would have expected that the value of the count property would be updated *before* the countChanged signal is emitted, regardless of the name of the parameter of the signal.

So I just verified that if I do that, this works:

import QtQuick 2.4
import QtSystemInfo 5.5
Item {
  InputDeviceModel {
    filter: InputInfo.Keyboard
    onCountChanged: console.log("keyboard count:", devices)
  }
}

However I’m wary of using that just yet, in case you decide to change the name of the parameter to 'count', my code would break. Please let me know if you plan to do so, and I’ll just hold off.

Also, the warning about object ownership and threads is still present. I think it should be investigated, as it’s usually a good indicator that something is not architected correctly.

Revision history for this message
Lorn Potter (lorn-potter) wrote :

I seem to remember @timo-jyrinki suggesting the 'devices' name at review time, so I must have not changed the base class. Not sure which one makes more sense. Suggestions? Opinions??

Revision history for this message
Olivier Tilloy (osomon) wrote :

How about not passing any argument to the signal emission? AFAIK, a lot of Qt *Changed signals don’t take any argument, so that would be in line with existing code. Of course we’d need to verify that by the time the signal is emitted the row count has actually changed.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Note that I’m affected by another issue that prevents me from making use of InputDeviceModel in QML: bug #1646080.

Changed in qtsystems-opensource-src (Ubuntu):
assignee: Lorn Potter (lorn-potter) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.