- User Since
- Jan 7 2017, 1:00 AM (299 w, 4 d)
Sep 3 2017
Removing redundant Qt5Widgets build dependency and adding qt5-svg as a rundep.
Aug 30 2017
Removing redundant pkgconfig dependencies per latest review comments.
Adding comment regarding proposed removal of Qt5Svg dependency.
Aug 24 2017
Rebuilding to update pspec.
Changed component and rearranged builddeps per review feedback
Changed component, cleaned up builddeps, removed static libraries and changed udev rules destination per review comments.
Changing component and disabling static libs per review feedback
Changing component per review feedback.
Accidentally created new differential for revision.
Jul 20 2017
Jul 11 2017
Jun 26 2017
Jun 22 2017
Mar 7 2017
Mar 6 2017
Feb 28 2017
Suggest as duplicate of T619. See that thread for workarounds and explanation.
Jan 21 2017
Jan 11 2017
@RenHoek I agree. Based on responses from other users this appears to be less of a SD card reader driver issue and more an issue with confusion about default behavior for removable storage. Principally:
- Removable media are not automounted.
- Removable media, mounted or unmounted, appear in 'Other Locations' rather than the root locations column.
Jan 10 2017
Looking through the source for v3.20 of gnome-settings-daemon, which is what registers and implements the systemd-inhibit hooks, I see that it does attempt to lock the screen by calling into the screensaver_proxy plugin. That proxy, however, doesn't actually proxy anything in v3.20. It implements Inhibit/Uninhibit but eats everything else like 'Lock' rather than pass the message on to the real screensaver proxy, which would forward to org.gnome.ScreenSaver and actually lock the screen.
Here's a workaround for those concerned about this issue:
- Create a file at /etc/systemd/system/suspend@.service like so sudo nano /etc/systemd/system/suspend@.service
- Plop in the following:
[Unit] Description=User suspend actions Before=sleep.target
So I believe I've mostly worked out what's going on here. The way this is supposed to work is that Gnome registers an inhibitor with systemd that delays systemd-logind's suspend action on lid close. gnome-settings-daemon is registering one, but it doesn't appear to work in the absence of gdm and/or other gnome components.
auston@obsidian /usr/lib/systemd/system-sleep $ systemd-inhibit --list Who: auston (UID 1000/auston, PID 898/gnome-settings-) What: handle-power-key:handle-suspend-key:handle-hibernate-key Why: GNOME handling keypresses Mode: block
@ChunkyPud That is helpful. Could you provide the output of systemd-inhibit --list on your working GNOME3/GDM setup?
Jan 9 2017
Other distros have struggled with this as well, see Mint. This needs a fix.
I had a theory this could be related to the kernel's hotplug config and rebooted with an SD card pre-inserted. My SD card was assigned to /dev/mmcblk0 and I could mount, read/write fine. Oddly enough, hotplugging is now working for me, even after reboot. So I'm not sure what was going on before.
I have the same issue on my Acer E15
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5287 (rev 01)
I believe there may be a slight kernel misconfiguration at present because while I see rtsx_pci_sdmmc, rtsx_pci and mmc_core in lsmod, I don't see mmc_block or sdhci modules. We should review the kernel config and see how it compares with what's described here: https://fitzcarraldoblog.wordpress.com/2015/04/28/realtek-5287-pcie-controller-for-memory-card-reader/
The referenced ticket suggests this is most likely the result of fontconfig misconfiguration but I don't see an offending config in ~/.config/fontconfig in my 2017.01.01.0 install.
Jan 8 2017
Fix is in patch attached to [T2131].
@joebonrichie Actually no need. I figured it out. ffmpeg was being compiled without the --enable-vaapi option so dependent apps didn't think it was available. I have a patch for the ffmpeg package that I've verified fixes this. Thanks for reporting the issue.
@joebonrichie Debugging mpv it seems like there could be a pixel format mismatch that's causing it to fall back on software decoding. Could you attach the mpv.log produced by this command on your working Arch install?
Jan 7 2017
I am able to repro this on my Kaby Lake (i3-7100U) system with Solus 2017.01.01.0. From the output of vainfo, VAAPI appears properly configured on my system. I see no explicit error messages from either VLC or MPV but logs and CPU usage indicate fallback to software rendering. Repros with known good media (Big Buck Bunny H.264/1080p) so it doesn't appear to be media-specific but could still possibly be related to AVC profile / level detection. Will continue to investigate.