chrome.system.display.getInfo returns invalid information for multi screen system |
|||||||||
Issue descriptionChrome Version: 64.0.3282.167 OS: ChromeOs 10176.72.0 Board: guado What steps will reproduce the problem? (1) Boot a system having two monitors connected, a regular monitor, and a DisplayLink monitor such as a MIMO. (2) Use a kiosk app and have it invoke chrome.system.display.getInfo right when it starts. What is the expected result? The result should show that both screens are present, with correct "hasTouchSupport" for respective screen. In this case, the regular TV without touch support, and the Mimo monitor with touch support. What happens instead? The result shows only the regular TV monitor, but with "hasTouchSupport:true", which is false. If we then set up a listener for the chrome.system.display.onDisplayChanged, and query things again when we see the next change (happens typically after 10 seconds), that result correctly shows the TV (without touch support) and the Mimo (with touch support). In summary, the two regressions from previous version M63, is that: * The TV is initially falsely shown to have touch support. * The MIMO display is not reported at start, but after quite a long time.
,
Mar 6 2018
,
Mar 6 2018
,
Mar 6 2018
,
Mar 7 2018
,
Mar 7 2018
Mat, does this problem happen when you invoke chrome.system.display.getInfo at particular small time window? Is that possible for regular user to hit this easily?
,
Mar 8 2018
waihong/bhthompson - do we have chameleons setup for automated regression anywhere? mnilsson - can you share how to repro as mzhuo doesn't see this in SVL - does this repro on tot? seanpaul - any random guesses on why we might have periodic failures on 64 for this?
,
Mar 8 2018
Complete guess: The display is taking time to register itself via USB, but the touchscreen isn't. So we wrongly associate the touchscreen with whatever display is present (the TV), and then correct it when the MIMO shows up. So 2 regressions, but the bug is probably just that the display isn't showing up immediately.
,
Mar 15 2018
Internal bug b/74225611 has logs demonstrating the effect. We have seen it in two rooms, and in one of them very reliably. It might be related to individual MIMO monitors?
,
Mar 19 2018
,
Mar 22 2018
The systems where this issue has been observed have the Mimo display connected through a StarTech ST4300USBM hub. grep:ing the system log for 'usb 1.6.1.3' from one of the instances gives these lines: 2018-03-15T10:25:12.996009+01:00 INFO kernel: [ 3.006039] usb 1-6.1.3: new high-speed USB device number 7 using xhci_hcd 2018-03-15T10:25:13.083015+01:00 INFO kernel: [ 3.093322] usb 1-6.1.3: New USB device found, idVendor=17e9, idProduct=016b 2018-03-15T10:25:13.083024+01:00 INFO kernel: [ 3.093330] usb 1-6.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2018-03-15T10:25:13.083025+01:00 INFO kernel: [ 3.093337] usb 1-6.1.3: Product: MIMO VUE HD 2018-03-15T10:25:13.083026+01:00 INFO kernel: [ 3.093341] usb 1-6.1.3: Manufacturer: DisplayLink 2018-03-15T10:25:13.083026+01:00 INFO kernel: [ 3.093346] usb 1-6.1.3: SerialNumber: 3 2018-03-15T10:25:16.862051+01:00 INFO kernel: [ 6.875342] usb 1-6.1.3: USB disconnect, device number 7 2018-03-15T10:25:18: <<<---------- Here the packaged app reports just the TV being present and erroneously reported to have touch. 2018-03-15T10:25:22.684049+01:00 INFO kernel: [ 12.701976] usb 1-6.1.3: new high-speed USB device number 11 using xhci_hcd 2018-03-15T10:25:22.768054+01:00 INFO kernel: [ 12.786764] usb 1-6.1.3: New USB device found, idVendor=17e9, idProduct=016b 2018-03-15T10:25:22.768071+01:00 INFO kernel: [ 12.786777] usb 1-6.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2018-03-15T10:25:22.768073+01:00 INFO kernel: [ 12.786785] usb 1-6.1.3: Product: MIMO VUE HD 2018-03-15T10:25:22.768074+01:00 INFO kernel: [ 12.786791] usb 1-6.1.3: Manufacturer: DisplayLink 2018-03-15T10:25:22.768075+01:00 INFO kernel: [ 12.786798] usb 1-6.1.3: SerialNumber: 3 2018-03-15T10:25:29: <<<---------- Here the packaged app reports both the TV and the Mimo with only the Mimo reported to have touch (correct). This behavior repeated itself during three reboots. I wonder if the disconnect is caused by the usb-hub, or if only the timing is different with the hub. (The enumeration seems slower with the hub than without, on the order of a few seconds, when testing with my dev system.) I will continue investigating logs for additional systems / configurations / Chrome versions to figure out what is going on here.
,
Jun 8 2018
Moving to long-term since we have a mitigation in place.
,
Jan 11
Assigned, but no owner or component? Please find a component and/or owner |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by malmnas@google.com
, Mar 6 2018