desktop October 2019

desktop@lists.fedoraproject.org

16 participants
16 discussions

F31 broken with Wayland on NVidia binary driver
by Christian Fredrik Schaller 09 Oct '19

09 Oct '19

Just noticed today that if I enable Wayland on the NVidia driver with current F31 packages I fail to even get the GDM login screen up. This used to work earlier in the F31 beta cycle. Anyone else here who can reproduce or for that matter are still able to run F31 with Wayland on top of NVidia binary driver? (By Under <editing /usr/lib/udev/rules.d/61-gdm.rules and commenting out the line that reads 'DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"' Christian

2 1

Gnome on F31: Qt applications cannot be fullscreened
by Ankur Sinha 08 Oct '19

08 Oct '19

Hello, Ran into another bug today while trying to watch netflix. Qt applications cannot be full screened. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1759490 This is more basic functionality---worth proposing as a blocker? -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

2 1

Re: Proposal: Toggle key criterion
by Adam Williamson 07 Oct '19

07 Oct '19

On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote: > As we discussed in today's blocker review meeting[1], I am presenting > a draft proposal for the toggle keys. I am proposing this as a *final* > criterion, but would not object to adding it as a beta criterion. > > == Keyboard toggle keys == > > For all release-blocking desktops, the Caps Lock and Num Lock keys > must correctly toggle the relevant behavior for the desktop and all > applications. The behavior must be consistent with the displayed > status on physical or virtual keyboards, where applicable. I think I'm on board with this; however, it'd also be good to get input from the desktop teams, as the responsibility for this ultimately falls on them. So CCing desktop@ and kde@. What do you folks think about this proposed criterion? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Re: Gnome on F31: X and Wayland clipboard weirdness(es)/regressions
by Ankur Sinha 06 Oct '19

06 Oct '19

On Fri, Oct 04, 2019 13:10:19 +0200, Kamil Paral wrote: > On Fri, Oct 4, 2019 at 12:50 PM Lukas Ruzicka <lruzicka(a)redhat.com> wrote: > > Both have been rejected as blockers due to being too "edge case". But > pasting into QT applications seems sufficiently broad to be considering > as blocking, I think. So if your problems are not related to those two > issues (e.g. have a VM running), please file new bugs and feel free to > propose them as blockers (or at least mark them as CommonBugs). > > > I am not sure you would be able to block on this, since no QT applications > are in standard Workstation installation. As far as I have seen, there is a > tendency not to block on additional software. > > > It would be of course up to debate. I'm just saying it's a good topic for > debate. +1, if not blockers, they should be listed in CommonBugs at least. I've filed two issues, and proposed one as a blocker now: https://bugzilla.redhat.com/show_bug.cgi?id=1758865 https://bugzilla.redhat.com/show_bug.cgi?id=1758873 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

1 0

Gnome on F31: X and Wayland clipboard weirdness(es)/regressions
by Ankur Sinha 04 Oct '19

04 Oct '19

Hello, I ran into an issues with copy/pasting on F31 with the new Gnome 3.34. Are these known, or are they expected and if not where should one file bugs please? gnome-shell-3.34.0-3.fc31.x86_64 --- Issue 1 ---- X clipboards cleared when applications closed Steps to reproduce: 1. Run gnome with Wayland 2. Install xsel and wl-clip to investigate the X and Wayland clipboard contents respectively 3. Open Gedit and write some text 4. Open a terminal (tile them both for ease) 5. In gedit copy the text: highlight and right click > copy 5. In the terminal, run the following commands: 5a. xsel -o (PRIMARY X selection buffer) 5b. xsel -o -b (CLIPBOARD X selection buffer) 5c. wl-paste (wayland selection buffer) 6. Then, close gedit, and re-run these commands. When gedit is running, the copied text is available to the X and wayland clipboards---all commands will show it. When gedit is closed, the `xsel` commands no longer show any results. The contents of the clipboards have been cleared. wl-paste still pastes the expected output. Is this expected behaviour? ---- Issue 2: cannot yank (copy) from gvim into Qt applications running on Gnome ---- Note that in the above, we used Gedit which I assume runs on wayland and accesses the required wayland clipboard properly. In the second scenario, if one copies anything from Gvim, it is available to the respective X clipboard, and the Wayland clipboard, but Qt applications running in Gnome cannot access any of this. Steps to reproduce: 1. Run gnome with wayland 2. Install xsel and wl-clip to investigate the X and Wayland clipboard contents respectively 3. Install qutebrowser and/or falkon 4. Open a terminal, open qutebrowser and falkon 5. Run a new Gvim instance: gvim -u NONE (ensures that no vimrc files are read) 6. Write two lines of text in Gvim (press i to enter insert mode, write a line, hit enter, write another line, press ctrl c to exit insert mode) 7. Copy the first line into the X CLIPBOARD selection buffer: go to the start of the line, press v to enter visual mode, go to the end of the line to highlight it; press "+y to yank to the + register (X CLIPBOARD selection) 8. In a terminal, check if this is available: 8a. wl-paste: shows copied text 8b. xsel -o -b: shows copied text 9. Try pasting in falkon or qutebrowser: ctrl v or right click > paste (greyed out): nothing shown. 10. Copy the second line into the X PRIMARY selection buffer: go to the start of the line, press v to enter visual mode, go to the end of the line to highlight it; press "*y to yank to the * register (X PRIMARY selection) 10a. wl-paste: still shows first line 10b. xsel -o -b: shows first line (as expected) 10c. xsel -o -p: shows second line (as expected) 11. Try pasting in falkon or qutebrowser: ctrl v or right click > paste (greyed out): nothing shown. 12. Open gedit, write something, copy it, try pasting in Falkon 12a. Irrespective of whether gedit remains open or not, the text is available the first time I try to paste it, and not any longer. 12b. On qutebrowser, though, this remains available, so this is a falkon thing/feature 12c. wl-paste continues to show this value as many times as you run it. 13. Since the x selections are cleared when gedit is closed (issue 1), vim cannot access the copied text at all using either the + or * registers later. So: - the wayland buffer is synced with the X CLIPBOARD buffer, which is fine: https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection - but none of this is available to Qt applications running in Gnome if if it originates from X buffers? I've created a new user and was able to reproduce this. While troubleshooting this on AskFedora, we also receive confirmation that this issue does not occur on F30. So, this is something to do with F31 and the new Gnome 3.34 bits. https://ask.fedoraproject.org/t/yanking-from-vim-to-qt-applications-on-gnom… -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

2 1

Re: Fedora-31-20190930.n.1 compose check report
by Adam Williamson 01 Oct '19

01 Oct '19

On Tue, 2019-10-01 at 00:13 +0000, Fedora compose checker wrote: > No missing expected images. > > Failed openQA tests: 5/152 (x86_64), 1/2 (arm) > > New failures (same test not failed in Fedora-31-20190928.n.0): > > ID: 460875 Test: x86_64 Workstation-live-iso desktop_update_graphical > URL: https://openqa.fedoraproject.org/tests/460875 > ID: 460896 Test: x86_64 KDE-live-iso apps_startstop > URL: https://openqa.fedoraproject.org/tests/460896 > ID: 460945 Test: x86_64 universal install_blivet_software_raid@uefi > URL: https://openqa.fedoraproject.org/tests/460945 These all look to be test glitches of one kind of another, all restarted. > Old failures (same test failed in Fedora-31-20190928.n.0): > > ID: 460862 Test: x86_64 Server-dvd-iso modularity_tests > URL: https://openqa.fedoraproject.org/tests/460862 This is a bunch of long-known issues, all are logged in Bugzilla. > ID: 460898 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload > URL: https://openqa.fedoraproject.org/tests/460898 This has been broken for ages, still waiting to be able to run ARM 32- bit tests on an ARM 64-bit host which should help. > ID: 460901 Test: x86_64 Silverblue-dvd_ostree-iso release_identification > URL: https://openqa.fedoraproject.org/tests/460901 This is an issue in the test caused by Silverblue getting clever with the contents of os-release, we will fix it in the test at some point. > Installed system changes in test x86_64 Workstation-live-iso install_default_upload: > 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service > 2 services(s) removed since previous compose: bolt.service, dbus-:1.8-org.freedesktop.problems@0.service loaded active running dbus-:1.8-org.freedesktop.problems@0.service > Previous test data: https://openqa.fedoraproject.org/tests/459681#downloads > Current test data: https://openqa.fedoraproject.org/tests/460867#downloads > > Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: > 1 services(s) removed since previous compose: bolt.service > System load changed from 0.30 to 0.52 > Previous test data: https://openqa.fedoraproject.org/tests/459683#downloads > Current test data: https://openqa.fedoraproject.org/tests/460869#downloads Hum, the dbus thing is obviously just a blip I should filter in check- compose, but 'bolt.service' disappearing seems interesting. Desktop folks, was that intended? IIRC it's to do with Thunderbolt support... > Installed system changes in test x86_64 KDE-live-iso install_default_upload: > Used mem changed from 888 MiB to 710 MiB > 1 services(s) removed since previous compose: pcscd.service > System load changed from 0.92 to 0.35 > Previous test data: https://openqa.fedoraproject.org/tests/459696#downloads > Current test data: https://openqa.fedoraproject.org/tests/460882#downloads KDE folks, is pcscd.service going away expected? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop October 2019