ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
melnary has quit [Remote host closed the connection]
melnary has joined #wayland
kts has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
kts has quit [Quit: Leaving]
mxz__ has joined #wayland
mxz___ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz___ is now known as mxz
mxz_ has quit [Ping timeout: 480 seconds]
anarsoul|2 has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
glennk has joined #wayland
<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
<dviola>
rebooting to a linux kernel LTS 6.6.x also makes it work, but I suspect that's using software cursors too
<dviola>
soreau: hrm, let me check
<soreau>
dviola: that's the test I used to track down the fix for the mesa MR
<dviola>
nice
<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..
<dviola>
I guess X11 just uses software cursors?
* soreau
is not the person to answer that question
yrlf has joined #wayland
<dviola>
soreau: yeah, could be
<soreau>
but if 6.6.x is working, test if it's sw or hw cursor
<soreau>
if it's hw and it works, then you only have to bisect the kernel ;)
<dviola>
sounds like a fun weekend project, heh
<soreau>
good thing it's the weekend, heh
<dviola>
yeah
<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
<dviola>
because on the host they also look weird, just not inverted
kts has joined #wayland
kts has quit [Quit: Leaving]
kode540 has joined #wayland
<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)
kode54 has quit [Ping timeout: 480 seconds]
kode540 has quit []
kode54 has joined #wayland
sally is now known as Guest8907
sally has joined #wayland
___nick___ has joined #wayland
iomari891 has quit [Quit: WeeChat 4.3.1]
Guest8907 has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
<soreau>
dviola: when you say 'wrong place', I guess you mean that the x position is correct but y is inverted?
<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
<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
iomari891 has joined #wayland
<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..
<soreau>
it seems you could use more info to know where to file an issue
<soreau>
but you have to be able to test the cursor in the host, as you said
<dviola>
yeah, makes me wonder if it was not just software cursor all along when it was "working"
<soreau>
or if it was hw cursor in host when it was working and then mesa broke everything?
<soreau>
hard to say
<soreau>
anyway, what gpu are you trying with?
__nick__ has joined #wayland
<dviola>
6700 XT
___nick___ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<soreau>
well if it has modifier support, the mesa patch probably won't do anything
<soreau>
IIRC, radeon GFX6-8 doesn't have modifiers and GFX9+ does, or something
iomari891 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<dviola>
I think I'll try recompiling the kernel+mesa on the host and see if it makes a difference
<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
<dviola>
and when I enable sway with debugging it doesn't log that too
<ade>
also curious is anyone here actually wayland developer writing or wrote window manager / gui toolkits?
<Fxzxmic>
Is there any way to write to the clipboard when the program loses focus?
<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.
<Fxzxmic>
It seems that wayland banned it because of safety concerns?
<linkmauve>
Also you are missing setting the correct edge for your resize, NONE isn’t really what you want.
<linkmauve>
Fxzxmic, you only write to the clipboard as a result of a user interaction with your surface, using a valid seat serial.
<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
<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.)
<linkmauve>
ade, yeah.
<ade>
yea, but i need to calculate which edge i'm at
<linkmauve>
Indeed.
<ade>
and only way i understand to calculate is to have maximum width / height and pointer x / y
<linkmauve>
ade, I used to contribute to Weston, GLFW, and a tiny bit to GTK.
<ade>
oh, good :p
<ade>
and what i was trying to say is that pointer and window coords have different units
<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.
<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.
<linkmauve>
Fxzxmic, not when a remote client makes an offer?
<ade>
wait, there is a surface scale that i can use to convert those units?
<Fxzxmic>
Otherwise I would need to write to the clipboard as soon as something is sent over, which I don't think is good.
<Fxzxmic>
Because when the user doesn't leave the program, that means the user doesn't want to use the clipboard contents.
<ade>
> A newly created surface has its buffer scale set to 1.
<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.
<ade>
so there shouldn't be any unit differentce
<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.
<Fxzxmic>
linkmauve: But when the user leaves the VNC client, I no longer have permission to write ah?
<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.
<linkmauve>
Fxzxmic, if your process exits, anything it copied doesn’t exist anyway.
<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.
<Fxzxmic>
linkmauve: Not really, I copy content from an editor, close the editor and still can paste it into the browser.
<linkmauve>
Is the editor a daemon of some kind?
<linkmauve>
Or maybe using X11, or maybe a clipboad manager?
<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.
<ade>
man, wayland is confusing af to me
<linkmauve>
Yes, your clipboard data can’t survive your process dying, unless you pass it to another process.
<linkmauve>
But I think X11 works the same, not completely sure.
<Fxzxmic>
I'm just here to ask me if you guys have a good solution in this situation.
karenw has joined #wayland
<Fxzxmic>
Otherwise I'd have to write over whatever the remote server sends to the VNC client every time.
<ade>
waiiit i think i understand now
<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.
<Fxzxmic>
Even when I know full well that users not leaving the client means they won't use it.
<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
<MrCooper>
kennylevinsen: FWIW, portals aren't flatpak specific, they're part of the platform some DEs like GNOME & KDE provide
<kennylevinsen>
Things explicitly say if they use buffer coordinates (damage_buffer being an example)
<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.
<MrCooper>
dviola: Xwayland will be around as long as users want to run X apps, current estimate ~forever
<kennylevinsen>
MrCooper: they are no longer flatpak-specific, but they are a flatpak project and originally driven by flatpak-specific needs
<Fxzxmic>
linkmauve: You're right, but for the most part it's still what I said.
<kennylevinsen>
Not picking a fight in that area btw
<dviola>
MrCooper: good, I have nothing against that, I want to game natively on wayland though :)
<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
<MrCooper>
well, or it could be an issue in the X client in the first place
<dviola>
MrCooper: interesting
<MrCooper>
making window resizes smooth with X is tricky
<ade>
so the scale value seems to be (or at least is very close to) 256 (idk why)
coldfeet has quit [Remote host closed the connection]
<ade>
when i put cursor at right-bottom i get about the same values as width and height
<ade>
but where does this 256 come from?
<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)
<ade>
i mean it's convenantly 2^8, but why?
<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.
<Fxzxmic>
linkmauve: I mean, after requesting the user's permission.
<kennylevinsen>
ade: are you perhaps misinterpreting a wl_fixed as an int? :)
<kennylevinsen>
It’s a fixed point fractional number
<ade>
printf("%d... ") ...
<ade>
yes im printing it as %d / int
<kennylevinsen>
See wl_fixed_to_double
<ade>
ah ok
<karenw>
Or `/256` or `>>8` if you don't care about the fractional part
<ade>
yes
<ade>
YESD
<kennylevinsen>
Yeah but don’t do that, it’ll break the moment you try hidpi
<karenw>
One day I'll bother to implement dpi scaling in my example wayland vulkan client.
<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.
<karenw>
If fractional scaling isn't available, should I treat wl_surface::preferred_buffer_scale as the hinted scale factor to use for UI?
<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.
<any1>
Providing a fallback in case the protocol is not implemented or not allowed would be a good idea
<Fxzxmic>
wayvnc developer? As a user program, though, it's not suitable for privileged protocol.
rasterman has joined #wayland
<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.
<karenw>
This is something that should be handled by compositor configuration (trating the VNC software as privledged by user request).
<karenw>
*treating
ade has quit [Ping timeout: 480 seconds]
<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.
<karenw>
Or it says yes and happy days.
<Fxzxmic>
But the current situation is that once the program loses focus, it can't interact with the clipboard.
kts has quit [Quit: Leaving]
<Fxzxmic>
Not even a chance to ask for permission.
<karenw>
That sounds more like a question for compositor devs to handle not the protocol itself.
<karenw>
But I see the problem yeah.
<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
<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
<any1>
Other VNC client have implemented this. I'd look at how they do it
<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.
soreau has quit [Ping timeout: 480 seconds]
<Fxzxmic>
any1: I've done what you said about sending the clipboard when the program gets focus.
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
<Fxzxmic>
Bad network
<any1>
The ideal solution would be to extend the RFB protocol to use the same model as wayland
<Fxzxmic>
Just writing to the local clipboard when program loses focus is not possible now.
<Fxzxmic>
any1: I did hear someone say that wayland should develop a new remote desktop protocol.
bindu has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
<any1>
If I were to create something new, I'd probably just make something based on WebRTC.
<any1>
... or quic + webcodecs.
<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.
<karenw>
Like not being able to mmap xkb keymaps as MAP_SHARED anymore
bindu has joined #wayland
Moprius has joined #wayland
Moprius has quit []
__nick__ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<karenw>
Why do a lot of wayland protocols provide int32_t values when negative values are nonsensical? Like buffer scale?
nerdopolis has joined #wayland
fmuellner has joined #wayland
<zamundaaa[m]>
Fxzxmic: making the data offers as they come is not an inappropriate solution, it's the only one that makes sense
<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
<zamundaaa[m]>
That's not how the clipboard works anywhere, for good reason
<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.
<Fxzxmic>
Continuously writing to the local clipboard just messes up the local clipboard.
<zamundaaa[m]>
It doesn't
<zamundaaa[m]>
Could you maybe describe what problem you expect to happen?
<Fxzxmic>
It will, because you can't choose which to keep on the remote server and which to send to local.
<zamundaaa[m]>
Why would you need to choose anything?
<Fxzxmic>
Because there is some content that you only want to copy and paste remotely, rather than sending it to local.
<zamundaaa[m]>
How would the remote desktop software know which is which?
<zamundaaa[m]>
Window focus is not a usable indicator for that
<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.
<zamundaaa[m]>
Sure, but it may also need the contents without window focus changing
<Fxzxmic>
I'm thinking about the most use cases, and I can't afford to take into account all the people with different habits.
<zamundaaa[m]>
It's way simpler to just do clipboards as they were and are always done everywhere
<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
<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.
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
feaneron has joined #wayland
__nick__ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
avu has quit [Quit: avu]
avu has joined #wayland
coldfeet has joined #wayland
KarenTheDorf has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
ade has joined #wayland
<ade>
so like previosuly i had a conversation about how to calculate egdes to resize window for wayland client
<ade>
(if anyone remembers)
<ade>
but like, isn't this compositors job?
<ade>
shound't it be compsoitors job?
<soreau>
generally speaking, it's the compositor's job to place/position windows/surfaces on the screen
<ade>
so what im doing should be redundant in the first place
<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
<ade>
i think i remember some window manager had a setting to set amount of pixels for edge resize
<ade>
like you could change the edge resize areas to be smaller/bigger for all windows
<soreau>
the decorations?
<ade>
probably
<ade>
no not the top title thingy
<llyyr>
you'd have to configure your compositor for that, if the application is using server side decorations
<ade>
the edges
<llyyr>
the edges are part of "decoration"
<llyyr>
resize edges*
<soreau>
yea, wayfire decoration plugins like pixdecor let you configure all those details
<ade>
so i should implement the decorator instead of calcuating edges
<soreau>
no idea what you're trying to do actually
<llyyr>
depends on what you're doing
<soreau>
heh
<ade>
i littearly just want resizable window
<ade>
that i can resize with mouse
<llyyr>
use xdg-decoration to negotiate server side decoration, the compositor will just handle it for you
<kennylevinsen>
(nit: doesn't work on GNOME where you have to use client-side decorations)
<soreau>
checkout wayfire with pixdecor plugin - you won't be disappointed :)
<ade>
i use gnome :(
<soreau>
oh..
<llyyr>
on gnome, you need to calculate which edge is being held and call xdg_toplevel_resize accordingly
<ade>
whatever, they will probably implement it sometime
<soreau>
that's really unfortunate for what you want
<soreau>
I doubt it haha
<llyyr>
ade: I'm confused if you're trying to develop an application or trying to hack an application into having resizable edges
<ade>
develop
<ade>
from scratch
<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
<kennylevinsen>
it's your drawn border after all
<soreau>
yea but if it's a tk, now it's.. not
<ade>
anyways, ill look into how to implement this xdg-decoration thing, thanks for help
<kennylevinsen>
ade: another option is just to use libdecor, which will give you client decorations for free
<llyyr>
does libdecor even handle resizing for you?
<ade>
actually i did look into libdecor and i did downloada demo from some git repo
<soreau>
and doesn't SDL optionally use libdecor?
<ade>
it seems like no, you still have to calculate it yourself
<ade>
you just map LIBDECOR_RESIZE_EDGE_<edge enums> to XDG_TOPLEVEL_RESIZE_EDGE_<egde enums>
<KarenTheDorf>
Having written a raw wayland client for vulkan, libdecor is amazing and you really should use it if not using a toolkit.
<KarenTheDorf>
Until the day gnome finally supports xdg decoration anyway. /s
<ade>
vulkan and wayland are like 2 hardest api's
<ade>
this is coming from the guy who just bearly got by understanding opengl
<ade>
opengl api*
<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.
<KarenTheDorf>
At least wayland has documentation isn't "wl_frobble_widget: Frobbles a Widget" though!
<KarenTheDorf>
Whoever maintains wayland.app is my hero
<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
<KarenTheDorf>
One of the biggest pain points of XLib is it was assumed the entire universe would be single threaded.
<KarenTheDorf>
This has made a lot of people very angry and been widely regarded as a bad move.
Fxzxmic has quit [Quit: Konversation exit!]
txtsd_ has joined #wayland
txtsd is now known as Guest8927
txtsd_ is now known as txtsd
Guest8927 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
Fxzxmic has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
The_Buhs6 has joined #wayland
feaneron has quit [Quit: feaneron]
The_Buhs has quit [Ping timeout: 480 seconds]
The_Buhs6 is now known as The_Buhs
ade has quit [Ping timeout: 480 seconds]
Guest7949 is now known as raghavgururajan
Fxzxmic has quit [Remote host closed the connection]
Lyude has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
overholts has quit [Quit: overholts]
overholts has joined #wayland
Lyude has joined #wayland
rasterman has joined #wayland
kasper93_ has quit [Ping timeout: 480 seconds]
<bjorkintosh>
well when Xlib was created, the world was very different from what it is now.
CoffeeImpliesCode has joined #wayland
<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?
<vyivel>
random guess: no buffer damage?
<CoffeeImpliesCode>
as in damaging the underlying wl_surface?
<vyivel>
yes (no idea if it's already done automatically though)
<CoffeeImpliesCode>
I am currently assuming that the redraw correctly works, as I am able to smoothly animate the screen with glClearColor
<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
KarenTheDorf has quit [Ping timeout: 480 seconds]
<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.
<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.
<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...
coldfeet has quit [Remote host closed the connection]
<kchibisov>
that looks like gl issue and not a wayland issue.
<kchibisov>
ensure that you don't glclear your draw arrays and eglSwapBuffers.
<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...
<kchibisov>
Do you resive the wl_egl_surface (or whatever it's called) to the size of your window?
<kchibisov>
as well as create it with some size that is not 1x1 or something.
<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
<kchibisov>
glClear will always clear the entire thing.
<kchibisov>
but if you don't set the veiwport for example, it'll break all the shaders.
<kchibisov>
but you say that you set, so sounds good.
<kchibisov>
anyway, it's an opengl issue and not wayland issue, since wayland just communicates buffers, not draws anything.
<FreeFull>
Have you tried seeing if it behaves differently in a different wayland compositor, btw?
<CoffeeImpliesCode>
so I just switched from Gnome to Hyprland and the issue persists
<kchibisov>
because it's either gl or egl context setup issue.
<kchibisov>
CoffeeImpliesCode: you can also share your code and I'll try to figure it out.
<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
<kchibisov>
CoffeeImpliesCode: given that you know rust, would suggest to port glutin example to zig.
<kchibisov>
it does exactly what you're trying to do.
<CoffeeImpliesCode>
I'll definitely look at it
<kchibisov>
you can even run it and ensure that it shows a triangle to you.
<CoffeeImpliesCode>
so the glutin version works flawlessly, I'll just try to diff my context creation vs theirs etc
<kchibisov>
CoffeeImpliesCode: I feel like the issue is that your shader expects vec3, but you pass vec2.
<kchibisov>
the vertex one.
<kchibisov>
make it vec2 aPoss and gl_Position = vec4(aPos, 0.0, 1.0);
<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)
<kchibisov>
glVertexAttribPointer has wrong data in it compared to what shader expects.
<kchibisov>
unless you've fixed it now.
<CoffeeImpliesCode>
? it's currently glVertexAttribPointer(0, 3, GL_FLOT, GL_FALSE, 3*sizeof(f32), null)
<kchibisov>
yeah, on github it was 2*sizeof.
<CoffeeImpliesCode>
Yes I fixed the stride argument, but that didn't do it
<CoffeeImpliesCode>
also I used to just pass vec2's but in my debugging I changed it
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
yshui_ has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
prg has joined #wayland
__nick__ has quit [Remote host closed the connection]
<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
<dviola>
I could also use the AUR mesa-git package I guess, any suggestions?
<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)
<soreau>
I install mesa to /opt/mesa and then I can test between system mesa and mesa git quite easily
<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
<soreau>
so it can find the updated version
<soreau>
for any other deps, if any are not found in the nonstandard prefix path, it will fallback to system path
<soreau>
but since you're on arch with latest packages, building mesa should be pretty straightforward
<dviola>
soreau: thanks, I will check that out
<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
<dviola>
it also goes away if I start the VM with -vga qxl and such
<dviola>
virtio-gpu issue maybe
<Ermine>
seems like virtio-gpu still needs a lot of work...
<dviola>
I bet it would work if I did gpu passthrough and I let amdgpu take over on the VM also
<dviola>
yeah, I'm still puzzled about why virito_gpu_dri.so doesn't show up in the lsof output
<dviola>
virtio_gpu_dri.so*
<dviola>
virgl started reporting the host driver also so maybe something related to that