Bug 1370970

Summary: accelerometer not working after boot
Product: [Fedora] Fedora Reporter: Christopher Tubbs <ctubbsii>
Component: iio-sensor-proxyAssignee: Igor Gnatenko <ignatenko>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 24CC: bnocera, ignatenko
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-16 08:35:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Christopher Tubbs 2016-08-29 05:00:59 UTC
Description of problem:
iio-sensor-proxy doesn't handle the accelerometer if the service starts too soon (before the accelerometer driver is loaded?), which causes screen rotation to not work

Version-Release number of selected component (if applicable):
iio-sensor-proxy-1.1-2.fc24.x86_64

How reproducible:
Nearly 100% on a fast-booting laptop. It only worked for me a few times on F23, and has never worked on F24.

Steps to Reproduce:
1. Reboot
2. Log in to GNOME session
3. Rotate screen

Actual results:
Screen does not rotate

Expected results:
Screen should rotate

Additional info:
Upstream bugs reported https://github.com/hadess/iio-sensor-proxy/issues/82 and https://github.com/hadess/iio-sensor-proxy/issues/85

Topic was discussed on the Fedora user list: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/OQTRWIUJU2ZWSDO2LYISORVWRHV4EFSO/

A (partial?) workaround is to change the service type to "idle" instead of "dbus".

Comment 1 Christopher Tubbs 2016-11-17 01:59:41 UTC
I think this should be reopened. The workaround described in the issue can be implemented in Fedora (changing "dbus" to "idle" service type), regardless of any pending upstream fixes.

Comment 2 Christopher Tubbs 2017-03-13 16:37:18 UTC
needinfo? flag was canceled, without providing any response to my request to reopen the issue for the stated reasons. I'm resetting the flag.

Comment 3 Igor Gnatenko 2017-03-13 16:51:26 UTC
(In reply to Christopher Tubbs from comment #2)
> needinfo? flag was canceled, without providing any response to my request to
> reopen the issue for the stated reasons. I'm resetting the flag.

1. Needinfo on closed bugs do not make any sense
2. Follow upstream for details
3. Workaround has been applied in upstream

Comment 4 Christopher Tubbs 2017-03-13 18:03:54 UTC
"Needinfo on closed bugs do not make any sense" - I disagree. Questions can occur at *any* point in the issue's lifecycle.

If workaround has been applied upstream, when will that upstream version make it in to Fedora, to fix the issue in Fedora? (another question, so I'm sorry... but I'm setting needinfo? flag again, so that question doesn't get lost.)

Comment 5 Christopher Tubbs 2017-07-05 21:24:16 UTC
I appreciate you don't like the needinfo? flag used on closed issues. However, can you please just answer the question instead of constantly removing the flag and ignoring the question? When will/has this workaround made it into Fedora?

Comment 6 Igor Gnatenko 2017-07-05 21:29:11 UTC
If you will check linked issues you will find in which versions in upstream bug got fixed. Compare with fedora version and you will see ;)

Comment 7 Christopher Tubbs 2017-07-05 21:44:28 UTC
That doesn't always work... because downstream packages can diverge from upstream. That's why I'm asking the POC/package maintainer. It's a simple question that the packager maintainer can easily answer but anybody else cannot, unless they dig deep.

Your minimalist responses to reasonable questions are very unfriendly and antagonistic. If you could just answer the question authoritatively, I would very much appreciate the professionalism and courtesy.

Comment 8 Bastien Nocera 2017-07-06 09:43:14 UTC
(In reply to Christopher Tubbs from comment #1)
> I think this should be reopened. The workaround described in the issue can
> be implemented in Fedora (changing "dbus" to "idle" service type),
> regardless of any pending upstream fixes.

No, because the race can still happen. It's a kernel bug anyway, so any discussion that doesn't involve looking at kernel traces is a waste of time.

Comment 9 Christopher Tubbs 2017-07-06 20:26:57 UTC
I understand it's a kernel bug, but the kernel devel is complicated, and moves slowly in fringe features like tablet support. A workaround which dramatically improves user experience by significantly reducing the probability of the race condition occurring, is NOT a waste of time, and it'd be nice if user experience were taken into account and the workaround at least considered, rather than simply ignored because it doesn't involve kernel traces.