01:08 soreau: llyyr: from client side? I don't think there's a way without additional protocol/ipc
01:09 llyyr: I mean for resizes started from the server side
01:09 soreau: right
01:09 soreau: if you're the server, you know
01:09 soreau: if you're the client, not unless the server tells you
01:09 llyyr: there's no protocol for the server to tell you
01:09 soreau: indeed
01:11 soreau: you would have to invent it for your compositor or try to shimy it into xdg-decoration somehow
01:12 soreau: but the question usually is, what do you need this information for?
10:34 bluetail: soreau mesa-git fixed the dolphin-emu opengl issue with invisible textures.
11:04 bluetail: uuuhm
15:22 zzxyb[m]: Wayland client selects a paragraph of text, and then clicks the blank area. At this time, does it have to call zwp_primary_selection_offer_v1.destroy()
16:45 gryffus_: Could Wayland please stop blacklisting resolution modes that both my adapter and my display supports, for no apparent reason?
16:46 psykose: not sure what wayland has to do with it
16:47 gryffus_: Perhaps I am crying on the wrong grave. In KDE, when I start session with X11, I have all the modes available, including 640x480
16:47 gryffus_: but in Wayland I get like only 5 choices. Not even 800x600
16:48 psykose: sounds like a bug report for kwin
16:49 gryffus_: OK I will try :x
16:49 Ermine:puts not-wayland-bug badge
16:51 emersion: gryffus_: there is a good change the KMS driver doesn't advertise this mode
16:52 emersion: X11 force-added a list of common modes
16:52 Ermine: but then how did X find out more modes?..
16:52 gryffus_: emersion: But with the same KMS driver, I get offered all available resolutions with X11
16:52 gryffus_: aha
16:52 emersion: well, xserver
16:52 gryffus_: Is it possible to identify it from xorg.log ?
16:52 emersion: no idea
16:52 emersion: drm_info would list modes advertised by the kernel
16:53 emersion: (KDE probably has a way to pick a custom mode)
16:53 gryffus_: drm_info lists only one mode
16:54 gryffus_: hmmmmm
16:54 gryffus_: interesting
16:54 gryffus_: does drm_info not respect EDID?
16:54 emersion: drm_info just reports what the kernel advertises
16:54 emersion: if you want to find out what the EDID advertises, you can use edid-decode
16:55 emersion: on /sys/class/drm/card*-*/edid
16:55 emersion: (replace * with values for your output)
16:55 Ermine: I wonder how libweston compares to wlroots
16:56 gryffus_: yeah, still only one mode reported (eDP)
16:57 gryffus_: So it's my display or eDP that fucks me up and X11 has just some workaround to force it "officially non-supported" modes ?
16:58 emersion: often times internal displays only advertise a single mode in their EDID
16:58 gryffus_: yes that is exactly my case
16:58 gryffus_: even xorg.0.log reports only one mode from the EDID
16:59 gryffus_: so what is happening here, how does X11 know the other modes
16:59 emersion: it's an hardcoded list
16:59 gryffus_: But still, I get different list on different machines. It has to compare it against something
16:59 gryffus_: Unless it has hardcoded list per graphics adapter
17:00 emersion: maybe filters by max resolution and aspect ratio or sth
17:00 gryffus_: But yeah result is, I can play Diablo 2 only on X11 :( :D
17:00 emersion: you should ask in a KDE channel how to force a custom mode on an output
17:01 gryffus_: I will try. Thanks!
17:01 emersion: np
17:01 Ermine: Well, many old games seem to rely on modesetting for fullscreen
17:03 kennylevinsen: it’s not guaranteed that the display will do anything usable on unadvertised resolutions, it’s much better to scale during render (either through viewport or not)
17:04 kennylevinsen: You can end up with it just showing a tiny square in the middle or a corner, or do an awful job stretching content…
17:05 Ermine: Fun story: when I was a child, some game failed to restore mode on exit, so windows got into 800x600 and I've got scared
17:59 bluetail: Ermine some displays have special Modelines for 'extra' settings. I doubt wayland implementations allow for modelines anymore.
18:02 kennylevinsen: sure they do, see man 5 sway-output for example - but modelines only describe display timings
18:03 kennylevinsen: You rarely need them though - the advertised modes have the full timings in the EDID, and when you select a custom one we just generate the timings using the standard algorithms
18:07 bluetail: what about VRR ranges though
18:07 bluetail: thats one thing that is super confusing me
18:08 bluetail: its something like, XXHz to XXXHz but within a range of allowed min and max
18:08 bluetail: But... Freesync doesnt work on many displays properly... so I dont re-attempt to use it
18:08 bluetail: and g-sync is unsupported since nvidia is unsupported because of proprietary garbage
18:11 bluetail: I read somewhere that they set Modelines for that which can be fine-tuned to not cross a certain threshold. I saw a picture of a Display with many Modelines that are meant to be 1:1 copied and pasted...
18:11 bluetail: in Windows... Whyyy
19:35 kennylevinsen: bluetail: VRR is still just one modeline - the fastest it can go. The variable part is a parameter for how much vblank can be extended if needed, but that’s handled at a lower layer - we just say “yes please” to the kernel.
19:37 bluetail: kennylevinsen when I tested VRR, my AMD 6950XT always ran at 100%, compared to having two displays capable on 144Hz but having vram at lowest setting. Plus, with it there, desktop felt sloppy (60Hz), and games did only feel good after I specifically assigned a rule. I felt really really confused by the whole endeavour.
19:39 bluetail: I ran couple of VRR tests, and none really made what I wanted to see. Even though it has 9.6 score rating for VRR. https://www.rtings.com/monitor/reviews/benq/zowie-xl2546k And I used DP. Ended up dropping it with votes from other people
19:40 bluetail: in my head, it would run at 60Hz when it does nothing, and at 240Hz when I game. But in practice it ran full blast always.
19:40 bluetail: kennylevinsen I will find the resource that up to xxx hz
19:41 bluetail: found it. https://youtu.be/pBMwP5ilDoM?t=164
19:42 bluetail: I know, it's intel, what do I even talk about. I am sure others can do, too. Many instruct their users for custom modelines to have a specific range for VRR.
19:45 Ermine: I don't think that compositor can figure out if a given client is a game...
19:46 bluetail: in sway, I had assumed max_render_time would be indicative
19:47 bluetail: if I understood correctly, you setup a time for rendering, e.g 16ms for 60fps, and it would take that
19:47 bluetail: so you could set up the rendering for a game to a specific value, and in my imagination it would then adjust its VRR automagically to it
19:48 bluetail: in sway you can set that on a window / application basis
19:49 bluetail: Though I'd argue that if you set that up you also need inhibition so for applications to go to sleep to not always max out the imaginative VRR mechanism
19:52 bluetail: Ermine I also hoped VRR makes movies / shows smoother because it would synchronize refresh rate to it. But it appears not likely
19:52 bluetail: right now I use smooth video project with all its artifacts. RIFE hopefully in future
20:07 Ermine: I don't see how vrr will improve this situation. Movies/shows are 60fps at best
20:17 psykose: something about making the refresh rate a integer multiple of the video rate makes playback better
20:24 bluetail: psykose except when displays can do the same refresh rate than the movie/show but are so horrible at that refresh rate that it's actually worse. For me, I also try to use the multiple, but it makes no sense for me to get a perfect match with this screen.
20:26 psykose: life is good until one dies, yes
20:31 kennylevinsen: bluetail: that video is about an EDID editor to rewrite what the monitor advertises if that is broken, not about any degree of normal configuration - the only normal configuration shown is the intel “VRR enable”
20:32 bluetail: kennylevinsen it is about going lower than the normal 60Hz
20:32 bluetail: for advertisement in various application... that's what I mean
20:32 bluetail: instead from 60 to 144 it goes now from 34 to 144Hz
20:32 kennylevinsen: We also don’t set up a 16ms loop for 60hz rendering - we render and give the content to the driver, the driver then gives us a heads up when that frame is done. As such, it’s the driver/gpu/display that decides the speed, as per the mode we asked for
20:33 bluetail: thanks for the explanation
20:34 bluetail: for both things. It's very confusing for me to understand with all details
20:35 bluetail: Yes, you are correct. The EDID thing is kind of a hack. Still it is something people do...
20:36 kennylevinsen: For VRR, it just changes what happens if we don’t have anything ready in time for the next 144hz frame. Without VRR, our content gets postponed till next time the display updates. With VRR, the driver and display just waits for us… until a point. Say, we need to give a frame every 7ms but it waits for us up to 32ms before giving up
20:37 kennylevinsen: Well it’s a hack in that you’re operating your monitor out of spec by changing its advertised support, but you do you. Some manufacturers have bad advertised modes.
20:37 bluetail: Oh I see. So then I completely misunderstood what VRR does
20:38 bluetail: When I watched the NVIDIA tech demo years ago, it appeared that VRR was sort of a motion smoother with low but constant FPS, making 30 FPS look like 60 FPS. Maybe they should have been more clear that it is meant to smoothen out the appearance by waiting longer, making the movement a bit delayed but less stuttery.
20:43 Ermine: marketing being marketing, huh
20:49 kennylevinsen: It’s just about allowing late content to be shown immediately instead of waiting a whole refresh cycle longer. At 60Hz, a late frame makes the frame time go from 16ms to 32ms which is jarring - with VRR, that might instead be 18ms.