06:05 dviola: so I've been trying to bisect the cursor issue with sway/wlroots, and can confirm that going back to sway 1.9 and wlroots 0.17.4 makes it work again, I couldn't bisect because newer sway wants newer wlroots
06:07 dviola: I noticed that reverting this commit helps: https://gitlab.freedesktop.org/iforbes/wlroots/-/commit/e3bd318547aeca306371ab78b1b01e3b06c6ba86
06:07 dviola: emersion, kennylevinsen: any ideas about that?
06:10 dviola: I like how easy it is to compile
06:12 dviola: I guess disabling that commit is the same as starting with WLR_NO_HARDWARE_CURSORS=1?
06:12 dviola: s/disabling/reverting/
06:15 dviola: oof, I think my issue might be the same as this: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3905
06:26 dviola: ah, found there's a MR already
06:26 dviola: on the mesa side
06:28 dviola: although I'm not sure that applies to my case
06:33 dviola: soreau: correct me if I'm wrong but is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725 related to that issue?
06:54 soreau: dviola: Perhaps? I'm not really sure in your case
06:55 soreau: it seems you have the issue in the hw cursor case
06:55 soreau: and it works when it's sw cursor
06:56 soreau: but easy enough to test and find out
06:58 dviola: yep, thanks
07:12 soreau: dviola: but if it's a wlroots issue you're hitting, then it won't help :)
07:17 dviola: ok
07:32 soreau: dviola: so the mouse cursor buffer is simply upside down but the position is correct?
07:32 dviola: right, but it's not correct
07:33 soreau: it's inverted?
07:33 dviola: yes, the software cursor appears in the right place though
07:33 soreau: so tthe entire cursor plane is upside down but everything else renders correctly
07:34 soreau: did you create a wlroots issue yet?
07:34 dviola: I don't know exactly where the hardware cursor is located but it's inverted, the software cursor appears in the right place
07:34 dviola: not yet
07:34 dviola: I'm trying to get more info
07:35 dviola: I will file a bug soon
07:36 soreau: dviola: maybe has something to do with i.e. https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3776 ?
07:37 soreau: seems like it might be easy enough to revert from 0.18 https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4621/diffs
07:38 soreau: maybe by 'fixing' mouse acceleration in virtualizzed drivers, it exposed this bug for you
07:40 dviola: yeah, I already tried to revert this commit, and it sort of helps but I suspect that makes it work with software cursors
07:40 dviola: I wonder if there is a way to verify whether hardware or software cursors are being used
07:40 soreau: hm, right.. but might be worth to mention in the bug report
07:40 soreau: dviola: you can easily check with wayfire showrepaint plugin https://github.com/WayfireWM/wayfire/issues/2492
07:41 dviola: rebooting to a linux kernel LTS 6.6.x also makes it work, but I suspect that's using software cursors too
07:41 dviola: soreau: hrm, let me check
07:41 soreau: dviola: that's the test I used to track down the fix for the mesa MR
07:42 dviola: nice
07:42 soreau: dviola: so it could be that you're facing two bugs, one (wlroots) enabled hw cursor support for your situation but this caused a bug because mesa or kernel..
07:42 dviola: I guess X11 just uses software cursors?
07:44 soreau:is not the person to answer that question
07:44 dviola: soreau: yeah, could be
07:45 soreau: but if 6.6.x is working, test if it's sw or hw cursor
07:45 soreau: if it's hw and it works, then you only have to bisect the kernel ;)
07:49 dviola: sounds like a fun weekend project, heh
07:49 soreau: good thing it's the weekend, heh
07:49 dviola: yeah
07:59 dviola: I wonder if the hardware cursors on the VM are supposed to still work if they are also broken on the host, sounds like I need to start testing things on the host first
07:59 dviola: because on the host they also look weird, just not inverted
08:20 dviola: I tried weston again and I get two cursors, I think weston just shows me a software cursor and the hardware cursor which is in the wrong place (same position as sway)
08:37 soreau: dviola: when you say 'wrong place', I guess you mean that the x position is correct but y is inverted?
08:42 soreau: also you can probably use a recording program like wf-recorder in the host (with slurp) to record the guest behavior without having the cursor flip during recording
08:44 dviola: yes, on weston I think there's a bit of overlap between the x as well, but it's a bit difficult to tell
08:49 soreau: hm. well if it's not wlroots-specifc, then maybe that mesa patch would help to restore hw cursor in the host at least..
08:49 soreau: it seems you could use more info to know where to file an issue
08:50 soreau: but you have to be able to test the cursor in the host, as you said
08:50 dviola: yeah, makes me wonder if it was not just software cursor all along when it was "working"
08:51 soreau: or if it was hw cursor in host when it was working and then mesa broke everything?
08:51 soreau: hard to say
08:52 soreau: anyway, what gpu are you trying with?
08:53 dviola: 6700 XT
08:57 soreau: well if it has modifier support, the mesa patch probably won't do anything
08:58 soreau: IIRC, radeon GFX6-8 doesn't have modifiers and GFX9+ does, or something
09:08 dviola: I think I'll try recompiling the kernel+mesa on the host and see if it makes a difference
09:30 dviola: it gets a bit confusing because wlroots' types/output/cursor.c has code to log hardware cursors on output '%s' but I don't see sway using that anywhere
09:30 dviola: and when I enable sway with debugging it doesn't log that too
09:33 dviola: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/output/cursor.c?ref_type=heads#L55
09:40 soreau: dviola: probably needs sway -d
09:48 dviola: still nothing, even with -d
10:05 dviola: soreau: that code gets triggered after I start recording the screen with wf-recorder
10:05 dviola: s/triggered/called/
10:05 soreau: yea I was thinking this..
10:09 ade: any1 online?
10:11 soreau: ade: they are joined to this channel, so they can see what you're typing
10:13 ade: lmao sry
10:15 soreau: if you meant 'is anyone online', then you probably should just ask your question and find out :)
10:16 ade: yes, i joined to ask, i typed out my question in reddit idk if its scummy to link it here
10:17 ade: so here is the question: https://www.reddit.com/r/wayland/comments/1gn6wtg/how_do_i_get_surface_width_and_height/
10:20 ade: also curious is anyone here actually wayland developer writing or wrote window manager / gui toolkits?
10:21 Fxzxmic: Is there any way to write to the clipboard when the program loses focus?
10:21 linkmauve: ade, you don’t get the surface width and height, since you are resizing you attach a buffer of the size you want to have now, after calculation.
10:22 Fxzxmic: It seems that wayland banned it because of safety concerns?
10:22 linkmauve: Also you are missing setting the correct edge for your resize, NONE isn’t really what you want.
10:23 linkmauve: Fxzxmic, you only write to the clipboard as a result of a user interaction with your surface, using a valid seat serial.
10:23 ade: Yea, i know i there is an enum for that, but i first need to need if statments to check which edge i'm at
10:23 linkmauve: (Also “writing to the clipboard” is conceptually the wrong operation, you offer something for the clipboard, but you will only write to it once another client is pasting from it.)
10:24 linkmauve: ade, yeah.
10:24 ade: yea, but i need to calculate which edge i'm at
10:25 linkmauve: Indeed.
10:25 ade: and only way i understand to calculate is to have maximum width / height and pointer x / y
10:25 linkmauve: ade, I used to contribute to Weston, GLFW, and a tiny bit to GTK.
10:26 ade: oh, good :p
10:27 ade: and what i was trying to say is that pointer and window coords have different units
10:27 linkmauve: ade, you are in control of your buffer’s size, of the surface’s scale, and you should already use those two pieces of information to determine whether a click is for resizing, moving, or application handling.
10:27 Fxzxmic: I'm writing a VNC client, and the best time to write the clipboard contents from the server I think is when the program loses focus.
10:28 linkmauve: Fxzxmic, not when a remote client makes an offer?
10:28 ade: wait, there is a surface scale that i can use to convert those units?
10:29 Fxzxmic: Otherwise I would need to write to the clipboard as soon as something is sent over, which I don't think is good.
10:30 Fxzxmic: Because when the user doesn't leave the program, that means the user doesn't want to use the clipboard contents.
10:30 linkmauve: ade, you define it: https://wayland.app/protocols/wayland#wl_surface:request:set_buffer_scale
10:30 ade: mmmh, is says:
10:30 ade: > A newly created surface has its buffer scale set to 1.
10:30 linkmauve: Fxzxmic, you don’t write to the clipboard until another client takes on your offer and reads from the pipe, at which point you start writing into it.
10:31 ade: so there shouldn't be any unit differentce
10:32 linkmauve: ade, you (the client) are in control of that, so you should already have all the state you need to compute where the user clicked on your surface.
10:32 Fxzxmic: linkmauve: But when the user leaves the VNC client, I no longer have permission to write ah?
10:32 linkmauve: There are other extensions you can use to get finer control over the scaling factor, like wp_viewporter, but that’s additional complexity you might not need right now.
10:33 linkmauve: Fxzxmic, if your process exits, anything it copied doesn’t exist anyway.
10:33 linkmauve: You can try with any local client, write something in it, copy it, close it, try to paste in another client, nothing will come out.
10:35 Fxzxmic: linkmauve: Not really, I copy content from an editor, close the editor and still can paste it into the browser.
10:36 linkmauve: Is the editor a daemon of some kind?
10:36 linkmauve: Or maybe using X11, or maybe a clipboad manager?
10:37 Fxzxmic: linkmauve: That's not the point, the point is that what I think is the best solution is not possible because of wayland's mechanics.
10:38 ade: man, wayland is confusing af to me
10:38 linkmauve: Yes, your clipboard data can’t survive your process dying, unless you pass it to another process.
10:38 linkmauve: But I think X11 works the same, not completely sure.
10:39 Fxzxmic: I'm just here to ask me if you guys have a good solution in this situation.
10:42 Fxzxmic: Otherwise I'd have to write over whatever the remote server sends to the VNC client every time.
10:42 ade: waiiit i think i understand now
10:43 kennylevinsen: ade: surface (logical) pixels are always the same, your buffer can have more buffer/physical pixels per surface/logical pixel for HiDPI if and only if your client actively decides to do that.
10:43 Fxzxmic: Even when I know full well that users not leaving the client means they won't use it.
10:43 dviola: soreau: so it looks like hardware cursors are used by default in sway (and some other compositors), if it doesn't work chances are it's a driver bug
10:43 MrCooper: kennylevinsen: FWIW, portals aren't flatpak specific, they're part of the platform some DEs like GNOME & KDE provide
10:43 kennylevinsen: Things explicitly say if they use buffer coordinates (damage_buffer being an example)
10:44 linkmauve: Fxzxmic, it completely depends, for instance if the user is using a clipboard manager they might want to have the full history, and not just the one after they unfocused your surface.
10:45 MrCooper: dviola: Xwayland will be around as long as users want to run X apps, current estimate ~forever
10:45 kennylevinsen: MrCooper: they are no longer flatpak-specific, but they are a flatpak project and originally driven by flatpak-specific needs
10:45 Fxzxmic: linkmauve: You're right, but for the most part it's still what I said.
10:46 kennylevinsen: Not picking a fight in that area btw
10:46 dviola: MrCooper: good, I have nothing against that, I want to game natively on wayland though :)
10:47 MrCooper: dviola: the issue in the brodie video is probably in the Wayland compositor, not in Xwayland; something like this was recently fixed in kwin, there was a blog about it
10:48 MrCooper: well, or it could be an issue in the X client in the first place
10:48 dviola: MrCooper: interesting
10:48 MrCooper: making window resizes smooth with X is tricky
10:48 ade: so the scale value seems to be (or at least is very close to) 256 (idk why)
10:48 ade: printf("%d %d %d %d\n", wl_surface_x / 256, wl_surface_y / 256, width, height);
10:49 ade: when i put cursor at right-bottom i get about the same values as width and height
10:49 ade: but where does this 256 come from?
10:50 Fxzxmic: linkmauve: Is there a need for such a protocol to allow programs to write clipboard even after losing focus? (With the user's permission, of course)
10:51 ade: i mean it's convenantly 2^8, but why?
10:51 linkmauve: Fxzxmic, I think it’s a very bad idea to give permissions to programs to manipulate the clipboard behind the user’s back, but maybe other people have different opinions.
10:52 Fxzxmic: linkmauve: I mean, after requesting the user's permission.
10:53 kennylevinsen: ade: are you perhaps misinterpreting a wl_fixed as an int? :)
10:53 kennylevinsen: It’s a fixed point fractional number
10:53 ade: printf("%d... ") ...
10:53 ade: yes im printing it as %d / int
10:54 kennylevinsen: See wl_fixed_to_double
10:54 ade: ah ok
10:54 karenw: Or `/256` or `>>8` if you don't care about the fractional part
10:54 ade: yes
10:54 ade: YESD
10:54 kennylevinsen: Yeah but don’t do that, it’ll break the moment you try hidpi
10:54 ade: ok, this problem is solved
10:54 ade: thaks guys
10:55 ade: ok ill use wl_fixed_to_double
10:56 ade: that's the correct printf version:
10:56 ade: printf("%g %g %d %d\n", wl_fixed_to_double(wl_surface_x), wl_fixed_to_double(wl_surface_y), width, height);
10:58 karenw: One day I'll bother to implement dpi scaling in my example wayland vulkan client.
10:58 karenw: Haven't even got round to integer scaling yet. It shouldn't be too hard since all I need to do is expose it reliably to the vulkan side.
11:01 karenw: If fractional scaling isn't available, should I treat wl_surface::preferred_buffer_scale as the hinted scale factor to use for UI?
11:01 any1: Fxzxmic: You can probably use wlr-data-control (or ext-data-control which is the same protocol in different namespace), but it is a privileged protocol.
11:03 any1: Providing a fallback in case the protocol is not implemented or not allowed would be a good idea
11:05 Fxzxmic: wayvnc developer? As a user program, though, it's not suitable for privileged protocol.
11:07 Fxzxmic: I think we're all already allowed to disable system shortcuts with the user's permission, so writing to the clipboard with the user's permission shouldn't be too much to ask.
11:07 karenw: This is something that should be handled by compositor configuration (trating the VNC software as privledged by user request).
11:08 karenw: *treating
11:08 karenw: Sure, you can *request* clipboard control from the compositor, but it may refuse, or never reply because it asked the user and they never responded.
11:08 karenw: Or it says yes and happy days.
11:10 Fxzxmic: But the current situation is that once the program loses focus, it can't interact with the clipboard.
11:10 Fxzxmic: Not even a chance to ask for permission.
11:16 karenw: That sounds more like a question for compositor devs to handle not the protocol itself.
11:16 karenw: But I see the problem yeah.
11:18 any1: Given that no one else is using the remote system, the clipboard is not going to get updated unless the client already has focus
11:20 any1: that is for the server -> client case. In the client -> server case, you can check the clipboard when the client gets focus. In most cases, you'll be pasting from that particular client
11:22 any1: Other VNC client have implemented this. I'd look at how they do it
11:22 Fxzxmic: Currently it's only possible to write the content to the clipboard as soon as the server sends it. An inappropriate solution is better than no solution at all.
11:24 Fxzxmic: any1: I've done what you said about sending the clipboard when the program gets focus.
11:26 Fxzxmic: Bad network
11:27 any1: The ideal solution would be to extend the RFB protocol to use the same model as wayland
11:27 Fxzxmic: Just writing to the local clipboard when program loses focus is not possible now.
11:29 Fxzxmic: any1: I did hear someone say that wayland should develop a new remote desktop protocol.
11:34 any1: If I were to create something new, I'd probably just make something based on WebRTC.
11:39 any1: ... or quic + webcodecs.
11:40 karenw: I am once again wishing there was a better way to get "all changes to protocol x between version N and M" other than git blaming the protocol xml. 95% of changes are just additions, but sometimes there's an actual change to catch me out.
11:41 karenw: Like not being able to mmap xkb keymaps as MAP_SHARED anymore
12:11 karenw: Why do a lot of wayland protocols provide int32_t values when negative values are nonsensical? Like buffer scale?
12:16 zamundaaa[m]: Fxzxmic: making the data offers as they come is not an inappropriate solution, it's the only one that makes sense
12:17 zamundaaa[m]: If I copy two things in a remote desktop, I want to have copied those two things, not just the last one after the application considers itself to have lost focus
12:17 zamundaaa[m]: That's not how the clipboard works anywhere, for good reason
12:21 Fxzxmic: zamundaaa[m]: It's really a situation that needs to be considered, as has been said above, but most situations aren't like that.
12:23 Fxzxmic: Continuously writing to the local clipboard just messes up the local clipboard.
12:24 zamundaaa[m]: It doesn't
12:26 zamundaaa[m]: Could you maybe describe what problem you expect to happen?
12:27 Fxzxmic: It will, because you can't choose which to keep on the remote server and which to send to local.
12:28 zamundaaa[m]: Why would you need to choose anything?
12:29 Fxzxmic: Because there is some content that you only want to copy and paste remotely, rather than sending it to local.
12:30 zamundaaa[m]: How would the remote desktop software know which is which?
12:31 zamundaaa[m]: Window focus is not a usable indicator for that
12:32 Fxzxmic: So I made the assumption that if the program loses focus, that means the user is going to use another program, and that's when the user is most likely to need the contents of the remote clipboard.
12:34 zamundaaa[m]: Sure, but it may also need the contents without window focus changing
12:36 Fxzxmic: I'm thinking about the most use cases, and I can't afford to take into account all the people with different habits.
12:37 zamundaaa[m]: It's way simpler to just do clipboards as they were and are always done everywhere
12:38 zamundaaa[m]: And waayy simpler than making a new protocol with a permissions system just so that you can make your program more badly integrate into the system
12:43 Fxzxmic: So now there's only one option. I started just to ask if there was anything or protocols in this area that I didn't already know.
14:38 ade: so like previosuly i had a conversation about how to calculate egdes to resize window for wayland client
14:38 ade: (if anyone remembers)
14:39 ade: but like, isn't this compositors job?
14:39 ade: shound't it be compsoitors job?
14:39 soreau: generally speaking, it's the compositor's job to place/position windows/surfaces on the screen
14:39 ade: so what im doing should be redundant in the first place
14:41 soreau: the parent surface doesn't know where it is on the screen; it only knows where its children surfaces are in relation to itself
14:42 ade: i think i remember some window manager had a setting to set amount of pixels for edge resize
14:43 ade: like you could change the edge resize areas to be smaller/bigger for all windows
14:44 soreau: the decorations?
14:44 ade: probably
14:44 ade: no not the top title thingy
14:44 llyyr: you'd have to configure your compositor for that, if the application is using server side decorations
14:44 ade: the edges
14:44 llyyr: the edges are part of "decoration"
14:44 llyyr: resize edges*
14:44 soreau: yea, wayfire decoration plugins like pixdecor let you configure all those details
14:44 ade: so i should implement the decorator instead of calcuating edges
14:45 soreau: no idea what you're trying to do actually
14:45 llyyr: depends on what you're doing
14:45 soreau: heh
14:45 ade: i littearly just want resizable window
14:45 ade: that i can resize with mouse
14:45 llyyr: use xdg-decoration to negotiate server side decoration, the compositor will just handle it for you
14:46 kennylevinsen: (nit: doesn't work on GNOME where you have to use client-side decorations)
14:46 soreau: checkout wayfire with pixdecor plugin - you won't be disappointed :)
14:46 ade: i use gnome :(
14:46 soreau: oh..
14:46 llyyr: on gnome, you need to calculate which edge is being held and call xdg_toplevel_resize accordingly
14:46 ade: whatever, they will probably implement it sometime
14:46 soreau: that's really unfortunate for what you want
14:46 soreau: I doubt it haha
14:47 llyyr: ade: I'm confused if you're trying to develop an application or trying to hack an application into having resizable edges
14:47 ade: develop
14:47 ade: from scratch
14:48 kennylevinsen: ade: with client-side decorations, you're the one drawing borders and shadows and such, so you're the one thta knows if a click is at the edge of a window for resize or not
14:48 kennylevinsen: it's your drawn border after all
14:48 soreau: yea but if it's a tk, now it's.. not
14:49 ade: anyways, ill look into how to implement this xdg-decoration thing, thanks for help
14:49 kennylevinsen: ade: another option is just to use libdecor, which will give you client decorations for free
14:50 llyyr: does libdecor even handle resizing for you?
14:52 ade: actually i did look into libdecor and i did downloada demo from some git repo
14:52 soreau: and doesn't SDL optionally use libdecor?
14:52 ade: it seems like no, you still have to calculate it yourself
14:53 ade: NO no no im wrong
14:53 ade: it kinda does handle it
14:55 ade: https://gitlab.freedesktop.org/libdecor/libdecor/-/blame/master/src/libdecor.c?ref_type=heads#L979
14:56 ade: you just map LIBDECOR_RESIZE_EDGE_<edge enums> to XDG_TOPLEVEL_RESIZE_EDGE_<egde enums>
15:02 KarenTheDorf: Having written a raw wayland client for vulkan, libdecor is amazing and you really should use it if not using a toolkit.
15:03 KarenTheDorf: Until the day gnome finally supports xdg decoration anyway. /s
15:06 ade: vulkan and wayland are like 2 hardest api's
15:06 ade: this is coming from the guy who just bearly got by understanding opengl
15:06 ade: opengl api*
15:09 KarenTheDorf: Ehhh... X is worse. But only because of 4 decades of cruft. Somewhere in the heart there's something that was originally decent for 1980-era hardware.
15:10 KarenTheDorf: At least wayland has documentation isn't "wl_frobble_widget: Frobbles a Widget" though!
15:11 KarenTheDorf: Whoever maintains wayland.app is my hero
15:15 ade: I actually never used x api, but i wound't be suprised that its bad given that it was designed for 90s mainframe terminals
15:17 KarenTheDorf: One of the biggest pain points of XLib is it was assumed the entire universe would be single threaded.
15:18 KarenTheDorf: This has made a lot of people very angry and been widely regarded as a bad move.
18:01 bjorkintosh: well when Xlib was created, the world was very different from what it is now.
18:12 CoffeeImpliesCode: Hi! To explore Wayland I have successfully created a Wayland window, an EGL context and an OpenGL 4.6 context, loaded with glad. I can glClear the screen and even animate the glClearColor, so swapping works. But when I try a drawing command like glDrawArrays, nothing worked. I checked and re-checked all my code now for multiple hours and can't find anything. Any ideas?
18:14 vyivel: random guess: no buffer damage?
18:18 CoffeeImpliesCode: as in damaging the underlying wl_surface?
18:18 vyivel: yes (no idea if it's already done automatically though)
18:21 CoffeeImpliesCode: I am currently assuming that the redraw correctly works, as I am able to smoothly animate the screen with glClearColor
18:22 CoffeeImpliesCode: also not clearing one of the 3 buffers leads to rapid flickering, so I assume EGL does the damaging. Also there only seems to be extension functions for partial damaging, so I assume it is done automatically in eglSwapBuffers
18:25 ManMower: running your program with WAYLAND_DEBUG=1 in the environment should confirm the damaging, but it's almost certainly done by egl, and done correctly.
18:27 ManMower: I suppose I'd check glGetError after every drawing command to make sure you're not doing something wrong on the gl side. if glClear is working, then I'm not sure what could be wrong at the wayland level.
18:29 CoffeeImpliesCode: glGetError return 0. Also glDebugCallback is silent. Also glad_debug functions (which check glGetError every time) are silent. I have no error info. It's just not showing anything...
19:05 kchibisov: that looks like gl issue and not a wayland issue.
19:06 kchibisov: ensure that you don't glclear your draw arrays and eglSwapBuffers.
19:15 CoffeeImpliesCode: Not clearing at all/ only clearing the first frame also yields not triangles rendered. I've tried every drawing mode, cross-checked every stackexchange "glDrawArrays draws nothing" post, I have a bound VAO, a valid VBO, I use the shader program (which links without issues), I am really running out of things that could be wrong...
19:18 kchibisov: Do you resive the wl_egl_surface (or whatever it's called) to the size of your window?
19:20 kchibisov: as well as create it with some size that is not 1x1 or something.
19:21 kchibisov: can also look into this https://github.com/emersion/hello-wayland/blob/opengl/main.c
19:22 CoffeeImpliesCode: I resize with egl_window_resize on every xdg_toplevel_event::configure and even on xdg_surface_events. The window has the size 800x600 and is fully colored by glClear. I also set glViewport to 800x600
19:22 kchibisov: glClear will always clear the entire thing.
19:22 kchibisov: but if you don't set the veiwport for example, it'll break all the shaders.
19:22 kchibisov: but you say that you set, so sounds good.
19:23 kchibisov: anyway, it's an opengl issue and not wayland issue, since wayland just communicates buffers, not draws anything.
19:23 FreeFull: Have you tried seeing if it behaves differently in a different wayland compositor, btw?
19:24 kchibisov: idk, if you can rust around you can run `cargo run --example window` from https://github.com/rust-windowing/glutin/ it'll draw you a triangle.
19:24 kchibisov: s/can/have/
19:28 CoffeeImpliesCode: so I just switched from Gnome to Hyprland and the issue persists
19:29 kchibisov: because it's either gl or egl context setup issue.
19:30 kchibisov: CoffeeImpliesCode: you can also share your code and I'll try to figure it out.
19:30 CoffeeImpliesCode: but the core profile loads correctly from glvnd, the egl context also works, I crash on every egl error, so I don't think I have any
19:57 CoffeeImpliesCode: kchibisov: okay so I cleaned up my code and pushed it onto github https://github.com/CoffeeImpliesCode/zeichnung although I should warn you, it's in zig...
19:59 kchibisov: CoffeeImpliesCode: given that you know rust, would suggest to port glutin example to zig.
19:59 kchibisov: it does exactly what you're trying to do.
19:59 CoffeeImpliesCode: I'll definitely look at it
20:00 kchibisov: you can even run it and ensure that it shows a triangle to you.
20:10 CoffeeImpliesCode: so the glutin version works flawlessly, I'll just try to diff my context creation vs theirs etc
20:14 kchibisov: CoffeeImpliesCode: I feel like the issue is that your shader expects vec3, but you pass vec2.
20:14 kchibisov: the vertex one.
20:15 kchibisov: make it vec2 aPoss and gl_Position = vec4(aPos, 0.0, 1.0);
20:18 CoffeeImpliesCode: but i pass it a vec3 no? (althought my stride was wrong as I used to pass a vec2, but fixing that didn't fix it)
20:19 kchibisov: glVertexAttribPointer has wrong data in it compared to what shader expects.
20:19 kchibisov: unless you've fixed it now.
20:19 CoffeeImpliesCode: ? it's currently glVertexAttribPointer(0, 3, GL_FLOT, GL_FALSE, 3*sizeof(f32), null)
20:20 kchibisov: yeah, on github it was 2*sizeof.
20:20 CoffeeImpliesCode: Yes I fixed the stride argument, but that didn't do it
20:20 CoffeeImpliesCode: also I used to just pass vec2's but in my debugging I changed it
21:10 dviola: I want to rebuild mesa to see if my sway cursor issue is a mesa regression, but I'm confused about how to rebuild it, I was thinking to just install it to /usr/local and override it in /etc/ld.so.conf.d/mesa.conf but I saw that sway also links to libglvnd and libdrm stuff, so I was wondering if I need to rebuild those too
21:14 dviola: I could also use the AUR mesa-git package I guess, any suggestions?
21:18 soreau: dviola: you can install mesa-git package system wide but if there's a problem, you'd have to revert.. but you can also install mesa to a nonstandard prefix (/usr/local will cause potential issues) and point LD_LIBRARY_PATH to $prefix/lib/$libdir when running an app to test (or compositor)
21:19 soreau: I install mesa to /opt/mesa and then I can test between system mesa and mesa git quite easily
21:20 soreau: for additional dependencies you might need like latest libdrm, you can also install everything into /opt/mesa and then point mesa at configure time with PKG_CONFIG_PATH pointed to $prefix/lib/$libdir/pkgconfig
21:20 soreau: so it can find the updated version
21:21 soreau: for any other deps, if any are not found in the nonstandard prefix path, it will fallback to system path
21:21 soreau: but since you're on arch with latest packages, building mesa should be pretty straightforward
21:33 dviola: soreau: thanks, I will check that out
21:42 dviola: I suspect it's multiples issues what I'm experiencing as you pointed out, hence the confusion... the inverted/duplicate cursor only appears in the VM
21:45 dviola: it also goes away if I start the VM with -vga qxl and such
21:49 dviola: virtio-gpu issue maybe
21:54 Ermine: seems like virtio-gpu still needs a lot of work...
21:54 dviola: I bet it would work if I did gpu passthrough and I let amdgpu take over on the VM also
22:04 dviola: yeah, I'm still puzzled about why virito_gpu_dri.so doesn't show up in the lsof output
22:05 dviola: virtio_gpu_dri.so*
22:10 dviola: virgl started reporting the host driver also so maybe something related to that