00:39 <soreau> I suppose the size is slightly off because weston-terminal resizes in character block increments

01:17 <pac85> yep by running it in floating mode it becomes clear that it resizes in character block increments. In Tiled mode the xorg WM forces a different size. The whole thing goes into a loop because my server tries to keep in sync xorg window size with the wayland's surface size.

01:23 <pac85> here is the code https://gitlab.com/pac85/waylandx I started from the simplest possible wayland server I could find, the code is pretty terribile

01:33 <pac85> and here is weston-terminal running on top of my thing running on top of xwayland running on top of sway https://telegra.ph/file/37c95160a1683c9dee4cb.jpg

02:27 <soreau> pac85: great shots

10:45 <udss> how to choose the program class in wayland? --class with StartupWMClass doesn't seem to work for me.

10:46 <udss> I want a firefox profile to show up as a different app. I made a .desktop file already and it's in .local/share/applications

10:58 <kennylevinsen> I have no idea what you mean by "show up as a different app". class/app_id doesn't affect anything on compositors/wms I use (unless one writes rules matching said class/app_id)

11:01 <udss> I mean that the profile should have a different Icon and window independent of other profiles including the main profile

11:02 <udss> My profile currently shows a different icon in the menu BUT after launching it, it changes to the main firefox icon and acts like just another instance of the main profile

11:03 <udss> my configuration used to work for xorg

11:03 <kennylevinsen> What menu?

11:03 <udss> the main menu, I'm using KDE

11:04 <udss> and in the KDE system monitor my profile shows as a different app

11:06 <udss> and yes, I'm running firefox with wayland enabled

11:09 <kennylevinsen> udss: if the "other profile" instance does not launch correctly but just spawns new with Windows in whatever was running, then that might be because of Firefox's remote process protocol. Firefox has a dbus version and an x11-specific version of this. Try with --no-remote or similar arguments

11:11 <kennylevinsen> udss: I have no idea how the KDE main menu works or why it updates its icon. You'd have to ask in a KDE channel or forum.

11:12 <udss> firefox -P newprofile -no-remote --class newprofileProfile <- This is my exec line

11:13 <kennylevinsen> Lacking a hyphen at --no-remote

11:14 <udss> changed it but still has the same problem

11:16 <udss> I read somewhere that I could use --name to solve this in wayland but I have no idea how

11:18 <kennylevinsen> udss: Wayland is just a protocol specification - application command line arguments are up to the applications

11:21 <udss> https://stackoverflow.com/questions/65772009/pygtk-application-wm-class-not-recognized-in-wayland

11:21 <udss> yes but I see others also had a similar problem. It worked in xorg but not wayland...

11:22 <kennylevinsen> udss: you're describing a few different problems I think - KDE menu weirdness and possibly that you don't get a window with the right profile. For KDE menu and .desktop file issues, you should ask in a KDE channel or forum. For Firefox not behaving (try from a terminal to rule out .desktop file/menu weirdness), Firefox channel/forum.

11:24 <udss> launched it from terminal still has the same problem

11:25 <kennylevinsen> which problem - does the window come up on screen with the profile you asked for?

11:26 <udss> no, it comes up as firefox. The main profile with the normal firefox icon although I've specified another icon in the .desktop file

11:28 <kennylevinsen> Icons doesn't matter right now. How do you test that it's the right profile? Different extensions/configuration?

11:30 <udss> it is the right profile, I opened about:profiles and checked it. It's the right profile but it's still being treated as a normal firefox window

11:37 <kennylevinsen> All Firefox windows are normal Firefox windows. Do you mean window grouping or something?

11:38 <udss> yes. In xorg the profile showed as a different application. It had its own icon (which I chose) and I could even open both profiles side by side

11:38 <udss> without them being grouped together

11:41 <udss> OMG got it, it was --name after all! I just have to add --name to exec and write the name of my profile!

11:44 <udss> thanks kennylevinsen, I hope you have a nice day and a happy new year!

11:45 <kennylevinsen> You too

13:06 <pq> emersion, daniels, I have to agree with swick here on the interpretation of the current presentation-time extension. It really give no info about when to *start* rendering, it only allows predicting when the next frame will be shown *if* it is ready by then.

13:07 <pq> Trying to use presentation-time to infer the deadline means you have to regularly miss the deadline and then roll back to guesstimate where the deadline is.

13:15 <zzag> I've been wondering how to make firefox nightly specify a different app id, but it's as easy as passing --name argument. Amazing.

13:19 <pq> kennylevinsen, would be really cool if there was a test app a la weston-presentation-shm that implemented various scheduling algorithms to try and minimize latency to screen, with controls on how long CPU and GPU drawing work takes each, per frame.

13:21 <pq> As in, run shader loop to ensure the GPU job per frame takes at least N microseconds. The same for CPU per frame work.

13:24 <pq> Having to miss the deadline to figure out where the deadline was and hope it doesn't move is kind of unwaylandy, because it's a visible glitch to the end user.

13:28 <pq> But if you're not going to artifically delay the start of rendering in a client, then you have exactly two choices: frame callback and presentation-time feedback event. Pick one based on whether you want minimal latency or maximal headroom, and then slowly adjust your LoD to try to keep not missing your predicted presentation time. Presentation-time extension should be just fine for this - that's what it has

13:28 <pq> been designed for. Not for client-side artifical delays to tweak latency to screen.

13:30 <pq> Even draw on presentation-time feedback event is a bit of a stretch, it wasn't really in the original plan, but with Weston implementation it worked too well to reduce latency.

13:31 <pq> I certainly welcome all the work to design a better presentation timing extension, even though I can't participate.

13:34 <pq> particularly as different compositors are only going to differ even more in their scheduling, e.g. don't latch in a new frame from a client for the next refresh until the GPU has finished drawing the client buffer.

13:40 <ishitatsuyuki> to the application, yeah — we definitely need a presentMargin like API

13:41 <ishitatsuyuki> although for non-game workloads I think it's better to do fixed latency window (as a fraction of refresh interval) rather than trying to be adaptive

15:12 <wlb> weston Merge request !749 opened by () libweston/compositor: Cache buffer damage for synced subsurfaces https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/749

15:21 <swick> ah, yes, testing out the deadline means you're going to miss it and that results in glitches. best argument for why you should probably not do that.

17:47 <kennylevinsen> The risk of missing the next deadline isn't any bigger with that approach though, and especially in frr we should be able to keep most glitches to an initial calibration phase - after that it should mostly just be reactive increase of the error margin when misses happen.

17:52 <kennylevinsen> pq: I should be more careful what I say, hah. Maybe I'll find time to take a crack at it - it would definitely be useful to study different behaviors.