ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
sozuba has joined #wayland
sozuba_tmp has joined #wayland
sozuba has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
kenny has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
Hello! I am trying to track down an obscure bug.
<JoshuaAshton>
Very occasionally when an XWayland client rapidly creates/destroys windows, I can get a wl_id from the XWindow's atom that corresponds to a resource that has a NULL implementation and NULL userdata, which should never happen.
<JoshuaAshton>
I've made sure to try flushing wayland stuff before trying to grab the resource and it made no difference. I also tried running my compositor with ASAN and it didn't find anything and could still repro.
<JoshuaAshton>
My next step might be to build libwayland with ASAN, because I am out of ideas...
<JoshuaAshton>
Wondering if anyone has seen this or something similar before?
<JoshuaAshton>
Hmmmmm
<JoshuaAshton>
This time when I repro-ed I got a completely different object
dcz_ has joined #wayland
<JoshuaAshton>
Am I misunderstanding the way ids in wayland are allocated? It looks like in wl_resource_destroy, all old IDs are reserved to return NULL, so a create with auto id should never get that one again, right?
<JoshuaAshton>
The ID is like 300, so it should fall down that path :S
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
danvet has joined #wayland
<emersion>
IDs are re-used
<emersion>
and picked by the client
<emersion>
(so that they can queue up multiple requests at once)
jgrulich has joined #wayland
tzimmermann has joined #wayland
everfree has quit [Quit: leaving]
everfree has joined #wayland
<JoshuaAshton>
emersion: I see, I don't see how any other compositor handles it differently to what we are doing in Gamescope though -- I wonder if this is a problem for other compositors too?
<emersion>
never seen that
<emersion>
my guess is that it has to do with threads
<JoshuaAshton>
I think the same would happen even if wl and x11 stuff was on the same thread, no? If you processed the wl stuff before, then handled the X stuff it would be essentially the same?
<JoshuaAshton>
Like you could end up in the same state, where you try and deal with a recycled wl id for some other resource from xwayland
<emersion>
hm
<emersion>
maybe threads expose a fundamental X11/Wayland race yeah
audgirka has joined #wayland
<ofourdan>
emersion, there's one thatyou reported precisely about this iirc :)
<emersion>
does Xwayland prevent clients from setting the WL_SURFACE_ID prop to garbage?
<ofourdan>
unlikely
<JoshuaAshton>
emersion: no
<emersion>
would be nice
<ofourdan>
but thatvalue is used only at first map iirc, once mapped the client changing the value won't do anything
<ofourdan>
I suspect this is a case where some XSync() and XGrabServer() from the X11 window manager would possibly help
<JoshuaAshton>
makes sense
<JoshuaAshton>
I can experiment with this
<emersion>
right
<JoshuaAshton>
If we wait for a full roundtrip from the X server after setting the atom+first map, that should also fix it
<JoshuaAshton>
Not sure what that means for performance/stalling the server though, may end up sucking
<ofourdan>
nah
<JoshuaAshton>
ofourdan: To which? :b
<ofourdan>
the stalling part
<JoshuaAshton>
ah
<JoshuaAshton>
ofourdan: Why would XGrabServer be useful here, shouldn't XSync be enough?
<JoshuaAshton>
(XSync on surface resource destruction)
<JoshuaAshton>
(or rather just before ;p)
<ofourdan>
the XGrabServer() was about the client chaning the value (which I reckon is unlikely)
<JoshuaAshton>
we don't have a surface <-> xwayland client association at this point yet, though
<ofourdan>
also, if the WM XGrabServer() then the client cannot unmap or destroy the window while the WM is dealing with Xwayland
hardening has joined #wayland
<JoshuaAshton>
I think its fine for the Window to be unmapped/destroyed, just that all of that needs to be processed before the wl_resource of its associated surface is
<JoshuaAshton>
Hm, I bunged an XSync( dpy, False ) in the destroy handler of the wl_surface resources if wl_id hadn't been handled yet for the associated surface and it didn't seem to help :thinking:
<JoshuaAshton>
Gonna grab tea then add some printf spam to see the timeline of things
Lucretia has quit []
Lucretia has joined #wayland
<JoshuaAshton>
I guess the client has not necessarily flushed its buffers containing the WL_SURFACE_ID atom stuff yet...? Which could be why
<JoshuaAshton>
ofourdan: Perhaps XWayland needs a force flush after setting the atom too?
<JoshuaAshton>
Not the client sorry, the xserver
<JoshuaAshton>
Meh, a FlushAllOutput in send_surface_id_event + the XSync didn't help.
<ofourdan>
yeah, I was about to suggest FlushAllOutput() since th eactual client isn't known in send_surface_id_event()
<ofourdan>
but FlushAllOutput() won't flush if the clietn has pending requests which is probably the case here
<JoshuaAshton>
oh
<JoshuaAshton>
Could force a flush even if not ready, but I don't know the implications of doing that
<pq>
I can't see how an XSync from wl_resource destroy request handler could help, because you cannot postpone resource destruction i.e. you are not allowed to process any further Wayland request on that connection until the resource is destroyed, and then XSync does not magically dispatch any X11 events, does it? You'd need to return to your main event loop to dispatch X11 and you cannot do that because for the
<pq>
former.
<pq>
I just left an idea in that Gitlab Issue; maybe Xwayland could delay destroying its wl_surface somehow?
<JoshuaAshton>
pq: In Gamescope, our X11 events are handled on a separate thread, but you are correct that it's dodgy. Even then, it has a hang opportunity if we are stalled on something the wl side needs.
<JoshuaAshton>
which is likely the case for wl surface id stuff :P
<pq>
right
<pq>
I also don't see how any amount of flushing from Xwayland could be reliable fix, because the Wayland compositor chooses which events and how many to serve first.
<JoshuaAshton>
pq: I thought about deferring destruction until the process of the wl surface id, but wasn't sure how to approach it. XWayland doesn't know which X client is the compositor to sync against here.
<JoshuaAshton>
The compositor could set a feedback atom, which XWayland reads back, and when that is set, it destroys the wl surface if it is deferring
<JoshuaAshton>
Or it could just set the surface ID atom back to 0 when its processed it, and that can be the feedback
<JoshuaAshton>
So when it wants to destroy the window, it can destroy the surface immediately if the atom is 0, or when the atom becomes 0
<pq>
JoshuaAshton, Xwayland should know who is the WM. At the very least, the root window has a property "owned" by the WM so that you cannot have multiple WMs at the same time, and the WM X11 connection fd is passed in on the command line explicitly.
<JoshuaAshton>
Oh, ye
<ofourdan>
pq: this is assumingthe X11 wm is the Wayland compositor
<pq>
I just don't know what's the best way to get to the WM Client.
<ofourdan>
that we can
<ofourdan>
there's code already for that (this is also how I granted server grabs for the X11 wm only)
<ofourdan>
but again, assuming the x11 wm is necessarily also the wayland compositor is forcing a design and closing the opportunity for different design
<pq>
JoshuaAshton, you also need to consider old XWMs who are not aware of the new handshake. Would not want Xwayland to leak wl_surfaces in those cases but to have the old behavior.
<pq>
ofourdan, where do you see that design restriction arising from?
<JoshuaAshton>
pq: Ez, just have yet another ATOM a Wayland compositor can set to indicate support for not being broken :D
<JoshuaAshton>
( :( )
<pq>
JoshuaAshton, easy sure, but forgetting it would be not nice. :-)
<ofourdan>
a new Xwayland protocol?
<ofourdan>
or even a use case forthe Xwayland X11 extension maybe
<ofourdan>
for older compositors, keep things as today
<pq>
what new Xwayland protocol? you mean as a Wayland extension?
<ofourdan>
either
<ofourdan>
either a new Wayland protocl for Xwayland, or use the (new) Xwayland X11 extension that we added in xorgporoto for Xwayland
<JoshuaAshton>
Also am happy to help drive work here, we need to fix this bug because its affecting our users right now
MajorBiscuit has joined #wayland
<ofourdan>
we could add a new Xwayland event to the xorproto etension
<pq>
ofourdan, or playing with X11 window properties like is the traditional way to patch up protocol.
<ofourdan>
yeah, not a big fan of those multiplying tbh
<pq>
yeah
<JoshuaAshton>
Haha, in Gamescope, basically all communication from Gamescope<->Steam is set as some property on the root Window x)
<ofourdan>
adding a prop to fix a race with a previous prop :)
<JoshuaAshton>
xprops as sync primitives
<pq>
ofourdan, so where does the assumption that XWM must be the same process as the Wayland compositor come from?
<ofourdan>
JoshuaAshton: and that's fine, it's between two x11 apps
<JoshuaAshton>
ye, it's just funny
<ofourdan>
pq, in the sentence "we can tell who is the Wayland compositor by determining the x11 wm"
<pq>
hmm... do we literally need that anywhere?
<JoshuaAshton>
I don't think so
<pq>
if they're not the same, then we must presume they talk to each other, and can that way guarantee whatever we need.
<ofourdan>
yup
<ofourdan>
that's teh compositor problem
<JoshuaAshton>
Another option would be `WL_SURFACE_ID_2` with the new behaviour
<ofourdan>
not a big fan of that either :)
<JoshuaAshton>
As for how a compositor can check if supported, it could just be another one of those features like `HAVE_XWAYLAND_NO_TOUCH_POINTER_EMULATION`
<JoshuaAshton>
ofourdan: Seems the cleanest so far, at least imo :b
<ofourdan>
we have a new X11 extension for Xwayland, I believe this falls within it's possible use, without using hacks
<ofourdan>
ofc this means the extension needsto be amended to add the needed functionality
<ofourdan>
but that would a cleaner design
<ofourdan>
ie a bit more work than a quick hack, but that's worth it in the long term
<JoshuaAshton>
What do you propose here? Replacing ATOM for it with a call to associate a xwl window with a wl_id here?
<JoshuaAshton>
Or merely versioning in the xproto
<pq>
maybe it would make sense to move the whole WL_SURFACE_ID into that X11 extension too?
<ofourdan>
that ^
<pq>
and not just the sync hand-shake
<ofourdan>
we would keep the props for backward compat and use a more robust ad-hoc mechanism provided by the xwayland extension
<JoshuaAshton>
btw, how is xwaylandproto.h generated?
<ofourdan>
for the compositors which support it
<JoshuaAshton>
I mean, I agree it's nicer, but it's also a lot more work than just adding a _2 atom, that doesn't really provide any benefit to users or us really now that it wasn't initially done like this.
<JoshuaAshton>
It's just more complex because we have two entirely separate paths to do the same thing in different ways...
<JoshuaAshton>
and compositors are also going to have to support two paths now potentially
<ofourdan>
yup, but this is core functionality, it deserves to be well implemented
<ofourdan>
adding hacks on top of hacks might sole the problem faster, but will not help in the long term - we hav the opportunity to solve the problem cleanly
<ofourdan>
so that woul be a preference
<ofourdan>
*my
<pq>
Is it agreed that the solution is to have Xwayland postpone destroying the wl_surface until the XWM acknowledges seeing both the wl_surface creation and the X11 Window <-> wl_surface association?
<pq>
or are there other ideas still on the table?
<JoshuaAshton>
How does a xwayland know that a X client (in this case the compoositor) has handled the new xproto event you are proposing? Would it make another call to say "yes I have handled this now" or something and then it can be defer destroyed if needed ?
<JoshuaAshton>
pq: I think that's the only reasonable solution here
<JoshuaAshton>
my other rationale for _2, is it also solves the problem of handshaking here easily
<pq>
if the basic idea is agreed, then would be nice to record that in the gitlab issue first before you hash out how it's implemented (X11 ext vs. Window props vs....)
<pq>
deferring destruction seems fine to me, but then I've been thinking about this for only like 10 minutes :-)
<ofourdan>
not necessarily an event, that could be a XwaylandSetSurfceId() or XwaylandReleaseSurface() or dunno, that need to be defined
<pq>
You can't destroy a wl_surface through X11, if that's what you're thinking.
<ofourdan>
no
<ofourdan>
I'm think a way for the wayland compositor to tell Xwayland that it can safely destroy the surface
<ofourdan>
*thinking
<pq>
oh, I was confused about the direction then
<JoshuaAshton>
XwaylandSetSurfceId() comes from server though, so that needs to be an event
<ofourdan>
no
<JoshuaAshton>
?
<ofourdan>
it's the client calling it
<pq>
no?
<JoshuaAshton>
no
<pq>
how could it?
<ofourdan>
ah Set
<ofourdan>
sorry
<ofourdan>
that should be an event indeed
<emersion>
would it be better as a Wayland extension? these are easier to propagate through the stack than going through xlib/xcb/etc
<ofourdan>
xlib/xcb implement the extensions :)
<emersion>
last time it took many months to get the disconnect flag :/
<emersion>
yeah but these are abandoned mostly
<ofourdan>
yeah, but as I said, I'd rather hav that done right than a quick hack to solve the problem
<emersion>
a Wayland protocol isn't a hack
<ofourdan>
neither is the xwayland extension
<ofourdan>
I was thinking of the props
<emersion>
I'm comparing x11 ext vs Wayland proto here
<pq>
if set_x11_window_id was a Wayland request, there would be no race to fix...
<emersion>
and stating that x11 protos are a pain
<JoshuaAshton>
pq: Yup, thatd solve a lot of other problems too
<JoshuaAshton>
Like pending surfaces
<JoshuaAshton>
and it solves the idea of handshaking support
<JoshuaAshton>
(well, pending surfaces in one direction, not the other)
<ofourdan>
an xwayland wayland protocol works as well for me - this could even be part of xwayland (being a private xwayland protocol)
<pq>
...or would there be a race? Are XIDs aggressively recycled too?
<JoshuaAshton>
We should consider the same race in the other direction -- what happens if the x11 window has been created/destroyed already and another Window has taken its place?
<JoshuaAshton>
jinx
<emersion>
alternatively, attach a uint64 ID which is never reused on both sides
<JoshuaAshton>
+1
<pq>
emersion, how would that work, when X11 Window is always referred through its XID via X11?
<JoshuaAshton>
you can just set it as an ATOM on a Window
<pq>
...which would defeat the whole point of designing a clean protocol :-)
<ofourdan>
hehe
<emersion>
if X11 IDs aren't aggressively reused, they would be enough yeah
<JoshuaAshton>
I've seen weird patterns to their usage before, but IDK what the pattern is
<ofourdan>
they aren't, afaik - they get reused only when the xserver runs out of fresh ids iirc
<ofourdan>
and you cannopt mix xids between client, as part of the mask is the client id as well
<JoshuaAshton>
oh oh
<JoshuaAshton>
please if we do the wayland ext
<JoshuaAshton>
PLEASE specify a display in it too
<JoshuaAshton>
Gamescope has multiple xwayland servers to deal with
<ofourdan>
display?
<JoshuaAshton>
and we footgunned one of our internal protocols this way
<ofourdan>
a display is set by the x11 connection
<ofourdan>
if you have multiple x11 servers, you have a connection to each one
<JoshuaAshton>
Yes, but the wl side needs to know which xid the server is associated to
<JoshuaAshton>
if we are doing this approach
<ofourdan>
ah the wl_display?
<JoshuaAshton>
no
<ofourdan>
the x11 display should be part of the wayland protocols?
<pq>
don't you already know which Wayland connection and which X11 connection go to which xwayland instance?
<JoshuaAshton>
wait nvm
<JoshuaAshton>
we know it from the xwayland client in this instance
<JoshuaAshton>
so thats fine
<JoshuaAshton>
In the protocol we footgunned, the xwayland client was not the one sending us XIDs
<JoshuaAshton>
which is why it strook fear into my heart :D
<pq>
do you mean, is "xwayland client" the xwayland or the X11 application? or XWM?
<pq>
or wl_client?
<JoshuaAshton>
xwayland server, just ignore everything I said after `oh oh` because I forgot that the xwayland server wl_client is the one sending us stuff. Whereas in the other protocol it was not.
<pq>
ok :-)
<JoshuaAshton>
This also solves malicious clients doing naughty things with the atom
<JoshuaAshton>
so thats cool
<emersion>
yup :)
<JoshuaAshton>
So what's the plan of action, who is doing what? I am happy to prototype out a protocol to a point that's functional today (maybe into tomorrow depending on how sleepy I get)
<emersion>
i'd be happy to review patches, or write any, but i'm a bit busy this week
<pq>
I'm afraid I can't really do more than IRC for this.
<JoshuaAshton>
Okay
<emersion>
i'll have more time next week
<JoshuaAshton>
ye, nw. I will have stuff to review by then
* emersion
currently in a train
<JoshuaAshton>
choo choo
<JoshuaAshton>
I will be at XDC too if anyone else is going
* ofourdan
is not going
* emersion
neither
<JoshuaAshton>
Nobody to discuss xorg with, sad.
<pq>
I don't travel.
<JoshuaAshton>
Alright, thanks for discussion everyone, gotta head out for a lil, and will prototype some stuff out. o/
<ofourdan>
pq: I remember seeing you at xdc helsinky :)
<emersion>
ofourdan: oh, lucky you
<ofourdan>
2016?
<pq>
ofourdan, that was the only time.
<pq>
this is the 20s, why do people still travel :-p
<ofourdan>
or 2015, I don't remember
<ofourdan>
lol
<romangg>
Since you guys just discussed Wayland protcols vs X atoms vs X extensions, what's the current state of https://gitlab.freedesktop.org/xorg/xserver/-/issues/1318? Is this only about what mechanism to use to communicate the scale or are there other questions open too?
<pq>
tongue in cheek maybe, but actually a serious question - I've been to e.g. scientific conferences in the past and I never understood why they require physical presence.
<romangg>
I think there have been two different MRs based on my one. One with X atoms and one with an X extension.
<JoshuaAshton>
pq: It's nice to meet people in person, admittedly less so given the current global pandemic though
<ofourdan>
I think there is vlue in /kowing/ the people we work with, remotely - otherwise we tento make a mental image of peope who are usaully quite far off from reality
<pq>
JoshuaAshton, I've never thought it's nice to meet people in person.
<ofourdan>
romangg: 3 different, last time I checked
<JoshuaAshton>
I am a theatre kid so probably disregard any opinion I have on social situations
<JoshuaAshton>
:P
<ofourdan>
pq: I think it helps with conflict resolutions for example, knowing the person who's on the other side of the keyboard, people can be be more forgiving thatn with some complete stranger
<ofourdan>
I think it's easier to assume good intent when you know the person is a good person, even on a bad mood :)
<romangg>
ofourdan: even more. nice. what's your current opinion about it? I believe without you on board there won't be much progress on it. Or are there alternative solutions in work right now?
<pq>
ofourdan, the mental image might be off, but it is based on everything that actually matters for the remote interaction and working together, while the "meatbag attributes" either have a positive impact which is unfair to everyone else, or a negative impact which is unfair to the person, and none of that is relevant to remote working together.
<romangg>
ofourdan: overwhelmingly yes, but 1% of the population are psychopaths. ;)
<ofourdan>
romangg: I wrote xorg/xserver#1318 precisely to state my opinion, but let others expose theirs. fwiw, I reckon Xwayland being a stop gap for legacy apps which will never be ported to Wayland, which are also those which are less likely to give good results in HiDPI. but again, that's just my take.
<ofourdan>
pq: surely, it might be unfair, but in my experience, it helps achiving better results. I think we are not computers, and direct human interactions helps :)
<romangg>
ofourdan: I agree with you in general but there are quite a few legacy applications not yet or never being ported to Wayland and that could give good results in HiDPI, right?
<ofourdan>
I guess the problem is that's a all-or-nothing approach, all X11 apps are trated the same, one way or the other
<romangg>
True, one could let the user decide that.
<ofourdan>
so it's unlikely we can find a solution that would please everyone
<romangg>
Then it would be good to have the ability to switch on/off Xwayland HiDPI on the fly.
<ofourdan>
yeah, and kde took that approach iiuc
<romangg>
So not how I did it in my first approach with the Xwayland command line argument for example.
<ofourdan>
what david wrote in the issue
<kennylevinsen>
we also cannot say if something will *never* be ported to Wayland, only whether it has been ported yet...
<romangg>
I haven't tried yet the kde solution but to me it sounded like it's not true Mixed HiDPI.
<romangg>
I think it's like Gnome's solution when not using xdg output just with extra steps.
<romangg>
But as said haven't tried yet and haven't looked into the code much.
<ofourdan>
neither have I
<romangg>
You know what, let me try that now.
<romangg>
;)
<ofourdan>
kennylevinsen: I am willing to bet that Motif will never be ported to Wayland :)
<romangg>
Just have to rebuild EVERYTHING...
<romangg>
kennylevinsen: Also a good example are old java apps, maybe legacy commercial apps. Not sure how well these support HiDPI though.
<kennylevinsen>
ofourdan: ... fair, I doubt anyone would be interested in contributing that support
<kennylevinsen>
I also know of no application using motif
<ofourdan>
kennylevinsen: there is still alot of in-house apps tha use Motif, it was a de-facto insutry standard on unix
<kennylevinsen>
romangg: Java AWT could grow Wayland support though, more likely than motif...
<ofourdan>
and also whether that particular wm is using xlib or xcb (as the former does sync by itself more that the latter)
<DemiMarie>
Suppose that it is using something like x11rb 🙂
<ofourdan>
…of which I know nothing
<LaserEyess>
15
<LaserEyess>
oops, sorry
<pq>
LaserEyess, no, I think that's a pretty good answer too. Equally useful than mine. :-)
<DemiMarie>
ofourdan: Rust bindings to the X11 protocol, presumably fully async
<DemiMarie>
I’m mostly interested in cases where the compositor must stop processing Wayland events to avoid races
<ofourdan>
so everything relies on "presumably"? :)
andyrtr has joined #wayland
<DemiMarie>
ofourdan: I am using x11rb as an example, nothing more.
<ofourdan>
ok
<DemiMarie>
this is a question about X11 and Wayland as protocols
<LaserEyess>
pq: I think the real answer to all of this is to just stop using xorg, then you wouldn't have to answer these questions
<LaserEyess>
simple!
<pq>
there is no Xorg here already :-p
<ofourdan>
LaserEyess: you are confusing Xorg and X11 :þ
<LaserEyess>
no x of any kind
<LaserEyess>
just ban the letter x
<LaserEyess>
(ok I'll stop shitposting now)
<pq>
DemiMarie, I can't think of any reason why some X11 thing would require freezing Wayland connections, but maybe I just can't imagine it yet.
<pq>
or freezing the whole compositor, really
abeltramo5391 has quit [Ping timeout: 480 seconds]
<pq>
especially when it's traditionally completely normal for an X server to have temporarily incoherent state until eventually everything catches up
<pq>
here I'm mostly referring to not having defined frame boundaries between draw operations, and extrapolating from that
Sheap has joined #wayland
abeltramo5391 has joined #wayland
<DemiMarie>
What specific X requests does an XWayland XWM need? I wonder if a minimal, fully-async library that did strong input validation would be a good idea.
<pq>
to what end?
<daniels>
DemiMarie: you can grep weston/xwayland/ for xcb_
<DemiMarie>
pq: because I want to support using XWayland from sandboxes without creating security risks
<pq>
making a proxy library async won't help anything if the Wayland compositor's XWM needs to know something from the X server before it can proceed, like... getting all the window properties so that it can make window management decision. The real question is, can all queries be deferred or is there actually a show-stopper somewhere.
<daniels>
input validation wouldn't make a difference when the validity of the input is determined by the three-way state synchronisation between the xwm client, the Xwayland server, and the compositor itself (as well as messages the client is sending through to the WM). a language can't statically determine that.
Company has joined #wayland
<Sheap>
Hi, I'm investigating developing a way to use an AR headset for virtual monitors. The trouble is, I'm not sure how this interacts with the linux environment. One fundamental thing I would need to pull this off within wayland (as I understand it) would be to have virtual outputs, which I could use to texture surfaces in an openXR app. Is this possible? Could anyone give some hints on where to start?
<daniels>
Sheap: https://xrdesktop.org - either use that if it works, or see what they do and adapt if not
<daniels>
or that too :)
<Levans>
Bilal Elmoussaoui: a new beta was released a few days ago, and there is a high probability that 0.30 will be released with the same contents soon (aka unless we find a problem with it in the coming days)
<daniels>
sure - the issue you've linked is a ton of work and everyone already has an overflowing to-do list, so if you want to see it happen then you'd need to be prepared to invest a significant amount of your own time to go build it, see where the problems are, solve the problems, and have it shipped in the real world
<MrCooper>
to others who like me sometimes get a bit depressed by all the negativity against Wayland flying around, https://lwn.net/Articles/908561/ may make you feel a little better
<ifreund>
just trying out rootful Xwayland for the first time from the head of master branch, this is pretty handy
<ifreund>
thanks to those who have been working on that recently
<bl4ckb0ne>
sounds like ill have to take care of the shadow drm dumb buffer soon
<ifreund>
I can now run the crappy java toolkit software that is utterly broken under my compositor's rootless xwayland in a rootful Xwayland window instead of on a separate TTY :)
rgallaispou has quit [Read error: Connection reset by peer]
fahien1 has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
fahien1 is now known as fahien
<DemiMarie>
daniels: “what a treat” can you elaborate?
<kennylevinsen>
an author has every right to make any technology choice they wish, but being incompatible with upstream choices impedes collaboration
anarsoul has quit [Read error: Connection reset by peer]
<DemiMarie>
I see
anarsoul has joined #wayland
<kennylevinsen>
so if you're suggesting that this effort is effectively upstreamed into Xwayland, then C would likely have been a better starting point. :)
<kennylevinsen>
(same goes if the xorg/wayland community was supposed to contribute)
cabal704 has quit [Quit: WeeChat 3.5]
fmuellner has joined #wayland
rv1sr has joined #wayland
<daniels>
yeah, they're both extremely niche
<daniels>
as said above, it's not something me (or anyone else who's been in these discussions for the last month or so since you picked it up?) is going to spend a great deal of time on anyway, and adding OCaml into that makes it even less likely
<kennylevinsen>
although tbf I think the Nix thing is an optional build dep
audgirka has quit [Quit: Leaving]
gspbirel56 has quit []
gspbirel56 has joined #wayland
<DemiMarie>
I don’t think that that will be rewritten in C, mostly because it is a replacement for a C++ project (Sommelier) that kept segfaulting.
<kennylevinsen>
For upstreaming, C is the only option right now. If in need of contributions, something more mainstream (Rust?).
<kennylevinsen>
also segfaulting is the good kind of bug, akin to a rust or go panic. it's the non-segfaults that suck. :)
<MrCooper>
unless the segfault is caused by memory corruption :/
<kennylevinsen>
true
<DemiMarie>
kennylevinsen: since this was a personal project (see blog posts) I think the author was more interested in something that was fun to program and got the job done.
slattann has quit []
rgallaispou has left #wayland [#wayland]
Sheap has quit [Quit: Page closed]
rgallaispou has joined #wayland
tzimmermann has quit [Quit: Leaving]
<kennylevinsen>
As mentioned that's perfectly fine, but you keep bringing it up in the context of doing this upstream (or contributing to it as a defacto solution I suppose)
ybogdano has joined #wayland
anarsoul has quit []
anarsoul has joined #wayland
rgallaispou has left #wayland [#wayland]
sargoe has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
danvet has quit [Read error: No route to host]
devilhorns has quit []
danvet has joined #wayland
jgrulich has quit [Remote host closed the connection]
skipet has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
sireuz has quit []
dcz has quit [Ping timeout: 480 seconds]
rv1sr has quit []
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
fmuellner has joined #wayland
Nimr-alIslam has joined #wayland
Nimr-alIslam has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2022-09-19 20:47:12)]
mvlad has quit [Remote host closed the connection]
Narrat has quit []
danvet has quit [Ping timeout: 480 seconds]
Arnavion has quit []
Arnavion has joined #wayland
cabal704 has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
hardening has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
ybogdano is now known as Guest966
Guest966 has quit [Read error: Connection reset by peer]