[Wayland-bugs] [Bug 103282] XWayland refresh rate locked to 60 Hz
https://bugs.freedesktop.org/show_bug.cgi?id=103282 Daniel van Vugt changed: What|Removed |Added See Also||https://launchpad.net/bugs/ ||1746163 -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 103282] XWayland refresh rate locked to 60 Hz
https://bugs.freedesktop.org/show_bug.cgi?id=103282 --- Comment #4 from Daniel van Vugt --- My monitor runs at 59.95Hz and this is what I see: Xwayland: $ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 428 frames in 5.0 seconds = 85.552 FPS 300 frames in 5.0 seconds = 59.993 FPS 301 frames in 5.0 seconds = 60.006 FPS 301 frames in 5.0 seconds = 59.983 FPS 301 frames in 5.0 seconds = 60.016 FPS WRONG 300 frames in 5.0 seconds = 59.999 FPS 300 frames in 5.0 seconds = 59.986 FPS 301 frames in 5.0 seconds = 60.004 FPS 301 frames in 5.0 seconds = 60.002 FPS 300 frames in 5.0 seconds = 59.998 FPS $ weston-info | grep refresh width: 1920 px, height: 1200 px, refresh: 59.950 Hz, Xorg: $ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 481 frames in 5.0 seconds = 96.146 FPS 300 frames in 5.0 seconds = 59.952 FPS 300 frames in 5.0 seconds = 59.956 FPS 300 frames in 5.0 seconds = 59.943 FPS 300 frames in 5.0 seconds = 59.948 FPS RIGHT 300 frames in 5.0 seconds = 59.953 FPS 300 frames in 5.0 seconds = 59.951 FPS 300 frames in 5.0 seconds = 59.949 FPS 300 frames in 5.0 seconds = 59.956 FPS 300 frames in 5.0 seconds = 59.947 FPS 300 frames in 5.0 seconds = 59.952 FPS -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 103282] XWayland refresh rate locked to 60 Hz
https://bugs.freedesktop.org/show_bug.cgi?id=103282 Daniel van Vugt changed: What|Removed |Added CC||daniel.van.vugt@canonical.c ||om --- Comment #3 from Daniel van Vugt --- *** Bug 104847 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, non-CSD GTK3 applications started with GDK_BACKEND=wayland *always* request CSD when they shouldn't
https://bugzilla.gnome.org/show_bug.cgi?id=792889 --- Comment #26 from Kyle De'Vir --- Sorry, was just seeking confirmation, but my request didn't quite come out right. :/ Now to pursue this on this KWin side... -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792895] Directory GtkFileChooserButton inside GtkPopover does not show menu in Wayland
https://bugzilla.gnome.org/show_bug.cgi?id=792895 Daniel Boles changed: What|Removed |Added Summary|Directory |Directory |GtkFileChooserButton inside |GtkFileChooserButton inside |GtkPopover is insensitive |GtkPopover does not show |in Wayland |menu in Wayland -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792895] Directory GtkFileChooserButton inside GtkPopover is insensitive in Wayland
https://bugzilla.gnome.org/show_bug.cgi?id=792895 --- Comment #7 from Daniel Boles --- I wonder if this is related to FileChooserButton refiltering its ComboBox model while the menu is popping up, trampling all over the assumptions the CB makes about its model. There are a couple of ugly hacks to deal with other problems caused by that, but maybe this is further evidence that the whole thing needs to be avoided. See https://bugzilla.gnome.org/show_bug.cgi?id=786835#c12 for that, and I'd appreciate reviews there, as opposed to the silence it's met so far. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792895] Directory GtkFileChooserButton inside GtkPopover is insensitive in Wayland
https://bugzilla.gnome.org/show_bug.cgi?id=792895 --- Comment #6 from Robert Roth --- Created attachment 367593 --> https://bugzilla.gnome.org/attachment.cgi?id=367593&action=edit Simple testcase Attached a simple vala testcase. compile with "valac --pkg gtk+-3.0 filechooser.vala". Steps to reproduce: 1. compile with "valac --pkg gtk+-3.0 filechooser.vala" 2. run the compiled filechooser application 3. click the About toggle button from the headerbar 4. click the filechooser button from the popover appearing expected: filechooser list/dropdown appears what happens: nothing 5. focus another window 6. click the filechooser from the unfocused window ( from the still visible popover), but without focusing the window before what happens: this time filechooser list/dropdown appears, select a folder this time on subsequent clicks of the filechooser it always works, it looks like the magic lies in the default selection of (None) -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, non-CSD GTK3 applications started with GDK_BACKEND=wayland *always* request CSD when they shouldn't
https://bugzilla.gnome.org/show_bug.cgi?id=792889 --- Comment #25 from Drew DeVault --- Sorry, what do you expect from me? So far as I can tell Sway and GTK+ are both behaving as expected. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, non-CSD GTK3 applications started with GDK_BACKEND=wayland *always* request CSD when they shouldn't
https://bugzilla.gnome.org/show_bug.cgi?id=792889 Kyle De'Vir changed: What|Removed |Added Summary|On kwin_wayland, GTK3 |On kwin_wayland, non-CSD |applications started with |GTK3 applications started |GDK_BACKEND=wayland |with GDK_BACKEND=wayland |*always* request CSD|*always* request CSD when |despite preferring SSD |they shouldn't -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, GTK3 applications started with GDK_BACKEND=wayland *always* request CSD despite preferring SSD
https://bugzilla.gnome.org/show_bug.cgi?id=792889 --- Comment #24 from Kyle De'Vir --- All good. I hope that Drew can help nail down whether this is a problem on the GTK3 side, somewhere, or not. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, GTK3 applications started with GDK_BACKEND=wayland *always* request CSD despite preferring SSD
https://bugzilla.gnome.org/show_bug.cgi?id=792889 --- Comment #23 from Daniel Stone --- (In reply to Kyle De'Vir from comment #22) > (In reply to Daniel Stone from comment #21) > > or that the server prefer SSD by default. > > Doesn't this seem... backwards? Why should clients that don't provide their > own headerbars request CSD on SSD-preferring compositors? Shouldn't they be > requesting SSD instead? What's the logic here? Yes, I misspoke. In this order: If the client demands CSD (e.g. has a headerbar), CSD will be used regardless of server preference. If the server prefers SSD and the client has not demanded CSD, SSD will be used. Else, CSD will be used. I don't know KWin or GTK+ well enough to answer your other questions, I'm afraid. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, GTK3 applications started with GDK_BACKEND=wayland *always* request CSD despite preferring SSD
https://bugzilla.gnome.org/show_bug.cgi?id=792889 --- Comment #22 from Kyle De'Vir --- (In reply to Daniel Stone from comment #21) > or that the server prefer SSD by default. Doesn't this seem... backwards? Why should clients that don't provide their own headerbars request CSD on SSD-preferring compositors? Shouldn't they be requesting SSD instead? What's the logic here? > That is as intended. You might have to find a slightly older app which > doesn't have a headerbar; as Drew suggested, gtk-demo would be a good start. gtk3-demo renders its own headerbar, so CSD makes sense. gtk3-demo-application, however, doesn't, so SSD should be preferred, no? When I make clients that provide their own headerbars ask for SSD, kwin_wayland draws SSD as it should, but clients that do not provide such, get nothing. Does this suggest a kwin_wayland bug to you, Daniel? Sorry if I'm repeating myself so often, because I'm intensely frustrated trying to figure out what the solution is supposed to be. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 792889] On kwin_wayland, GTK3 applications started with GDK_BACKEND=wayland *always* request CSD despite preferring SSD
https://bugzilla.gnome.org/show_bug.cgi?id=792889 Daniel Stone changed: What|Removed |Added CC||dan...@fooishbar.org --- Comment #21 from Daniel Stone --- (In reply to Kyle De'Vir from comment #7) > Created attachment 367474 [details] [review] > Dirty hack to make GTK3 Wayland windows request SSD instead of CSD > > I created a dirty hack to force GTK3 windows request SSD instead. This is only called from gtk_window_enable_csd(). The path to calling this requires that the client explictly request CSD (e.g. it has a headerbar it draws itself, containing title + widgets), or that the server prefer SSD by default. That is as intended. You might have to find a slightly older app which doesn't have a headerbar; as Drew suggested, gtk-demo would be a good start. -- You are receiving this mail because: You are on the CC list for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 102649] Mouse taps (?) detected while typing
https://bugs.freedesktop.org/show_bug.cgi?id=102649 --- Comment #45 from Rimas Kudelis --- Just to explain this once more: "thee cursor jumped between "t" and "ermina"." means that while I was typing the word "terminal", text cursor was moved elsewhere after I typed letter "t", so "ermina" was inserted elsewhere in the text. -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
[Wayland-bugs] [Bug 102649] Mouse taps (?) detected while typing
https://bugs.freedesktop.org/show_bug.cgi?id=102649 --- Comment #44 from Rimas Kudelis --- (In reply to Peter Hutterer from comment #43) > "thee cursor jumped between "t" and "ermina"." - wait, I though we're > talking about mouse taps detected? > > Now that I'm reading the log again: the problem seems to be that your > trackpoint sends random motion events. This is one case of movement while > typing: <...> > event14 is your trackpoint and it's not captured by the disable-while-typing > because that's for touchpads only. So the question now is *why* is this > thing sending the occasional movement? Are you touching it or just hammering > on the keyboard hard enough? I don't mind motion events. Whether I ram the keyboard, or accidentally manage to touch the trackpoint doesn't matter, as the trackpoint doesn't send click events. I guess I should have been more explicit: "thee cursor jumped between "t" and "ermina"." referred to the text cursor, not mouse pointer. The point is, if I leave my mouse pointer above some place in the text and keep typing, eventually an accidental and unwelcome tap is sent, which moves the text cursor under the mouse cursor, thus messing up my text. This interferes with me coding, as well as typing text (like this comment here – this has happened a few times already). Hope this is cleared up now. > As for starting multiple commands at the same time, screen is your friend: > $> cat test.screenrc > zombie kr > screen ls -lR > screen echo "hello" > $> screen -c test.screenrc > > Will start 2 screens with ls and echo. Adjusting this example should give > you almost exact timestamps in evemu and libinput debug-events. Thanks, I'll try this if necessary (that is if my previously attached logs aren't sufficient again). -- You are receiving this mail because: You are the assignee for the bug.___ wayland-bugs mailing list wayland-bugs@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
