06:40MrCooper: whot: still broken with libinput master
06:40MrCooper: /usr/bin/ld: ./.libs/libshared.a(libshared_la-shared.o): undefined reference to symbol 'udev_device_unref@@LIBUDEV_183'
06:40MrCooper: //lib/x86_64-linux-gnu/libudev.so.1: error adding symbols: DSO missing from command line
06:40MrCooper: looks like -ludev is missing somewhere
06:41whot:is still unable to copy/paste reliably on first try
06:41whot: also, why don't I get this one
06:42MrCooper: that fixes it
06:42MrCooper: something else must pull in libudev for you
06:43MrCooper: BTW, I've switched my build script to meson, so this might be the last time I catch an autotools build failure
06:43whot: MrCooper: https://da.gd/nb54L, I think that's the right now
06:43whot: yeah, I just wonder what pulls it in
06:44MrCooper: the former paste already fixed it, so I assume this one will too
06:44whot: MrCooper: the way things are going, autotools will go dodo after the 1.8 release anyway :)
06:45MrCooper: BTW, my IRC client also tends to fail to join this channel lately; might be related to the configuration change to ban web gateways?
06:47whot: I think my irssi config is just busted
06:48MrCooper: i.e. it fails to join this channel when connecting to FreeNode, joining later manually works fine
06:58jadahl: whot: debian defaults to some setting causing libtool not to link to all dependencies up the tree. fedora doesn't have such a patch on libtool. could be that
07:55whot: jadahl: ah, right, that could be it, thanks
08:09xerpi: daniels, hi there
08:09xerpi: was your vacation fine?
08:19whot: ofourdan: want to re-run the key combo vs string discussion, or are you tired of it? :)
08:19ofourdan: I'll rest once it's accepted :)
08:19ofourdan: jadahl is around?
08:20ofourdan: sorry I got kicked and didn;t realized I needed to re-indeity with freenode/rejoin the channel, did you start the converssation already?
08:20whot: was waiting for you
08:20whot: figured that's the easy way, to wait for the guy who actually tries to deal with that stuff instead of just talking to myself :)
08:21ofourdan: oh c'mon, we remotees often talk to ourselves, I'm sure you do! :)
08:22ofourdan: whot, so, the idea of sending the key combo event sequence as it sould occur was actualyl jadahl's
08:24ofourdan: the benefit of that approach is to be very flexible, as it can "describe" pretty much anything
08:24ofourdan: the downside is that the client needs to make sense of those, which might not be trivial
08:25ofourdan: the problem I see with sending a string is that it would need to be "standardized" if the client wants to implement/reuse the same shortcut
08:25ofourdan: that, plus the localization issues possibly
08:29whot: well, the standardisation would be difficult either way, because the same sequence could be rendered differently by the compositor and the client
08:29ofourdan: but the compositor doesn't need to render it, does it?
08:30whot: I'd envision this as a basic overlay immediately after the first inhibitor is requested, similar to youtube's full screen
08:31ofourdan: note that this mechanism would be for badly behaved clients, good ones wouldn't need it
08:32ofourdan: like for example I am running gnome-shell + gtk+ with thos implemented without any key combo and haven;'t felt th need for it yet ...
08:32whot: in which case the shortcut doesn't need to be the same, I guess. You could make this a compositor-wide shortcut to kill nasty clients
08:32ofourdan: ouch :)
08:32whot: gently, of course
08:32whot: maybe tickle them to death or something
08:33ofourdan: the idea was to force the inhibitor deactivation, rahter than killing the client
08:33whot: more seriously, hit some combo and the compsitor overlays some sort of "what do you want to do here" box
08:33whot: because by the time you have to force it, you likely also want to make the client share the pain
08:34whot: and that same combo can then be used for any misbehaving client (similar to the force quit/wait dialog right now)
08:34whot: note: I'm not claiming it's the best solution, this is more thinking aloud. I just have a bad gut feeling about the key sequence approach
08:36ofourdan: so you wouldn't advertise the key combo at all to clients, or you reckon the string is needed still?
08:36ofourdan: (what I don;t like much about the ke ysequence myself is its complexity)
08:36jadahl: ofourdan: kind of around, at a mini hackfest
08:37ofourdan: oh, hey jonas :)
08:37ofourdan: jadahl: whot and I were discussing the key combo definition in the protocol shortcut inhibitor
08:37whot: ofourdan: good point, means neither sequence or string is required then
08:38jadahl: ofourdan: did it turn out awkward?
08:40ofourdan: whot doesn't like it much :)
08:40ofourdan: I didn;t implement it in mutter yet
08:41ofourdan: but I agree it looks a bit awkward
08:41whot: I'm going to argue that right now the protocol is better off without it (or even the string) and only once we figure out we really need it, we can add it later
08:41sham1: As far as key combo definitions go, I would go with strings myself because those things mightn't be as limited as some other ways of representing keycombos
08:42whot: because the only benefit i can see is that the client may want to use the same combo, but I'm not sure that's really worth the complexity
08:43whot: and even if the client uses the same combo, you'd then 90% of the time run the force-disable code first, followed by the client destroying it, seems superfluous
08:44ofourdan: I don't even think reusing the same key combo is desirable, the "for de-inhibitor" is not the same as destroying an exiting inhibitor from the client
08:46ofourdan: I am thinking of apps like virt-virwer or vnc-viewer which, iirc, have their own combo to release the "grab" (on x11), these woul remain whereas the compositor would still allow to force kill an existing inhibitor whent he client is unwilling to do that itself
08:47jadahl: the only concern I had that would need exposing the key combo is to have the same combo to reliably disable as tho one to enable, (like Ctrl+Shift in some VMs), but if the compositor one should be more special and reminded some how not by the client, then I guess its pointless
08:49whot: maybe go without the keyboard combo bit for now and add it later if we realize it's required?
08:50whot: I mean, that's what unstable protocols are for :)
08:50jadahl: sounds reasonable
08:50jadahl: i can understand why we would want to wait with it
08:50ofourdan: I would definitly approve that :)
08:50whot: (plus, it's called "trial and error", not "trial and got it right the first time")
08:50jadahl: (i also don't think we should use wl_keyboard for it too, now that I skimmed through the last patch :P)
08:51jadahl: (but that'd of course make things even more complicated and less suitable for an initial version)
08:51whot: I suspect implementing this via wl_keyboard is going to be quite nasty in the client anyway
08:51ofourdan: ok, so you are both ok if I remove that all bunch from the procotol for now?
08:51whot: but you could always mirror wl_keyboard's modifier/key events
08:51whot: ofourdan: yep
08:52ofourdan: cool, perfect!
08:52jadahl: yea, would have to dup key and modifier probably
08:53ofourdan: whot: I am not sure I see the indentation mismatch you pointed out
08:54jadahl: ofourdan: any idea how gnome-shell would show the disable-key-combo? maybe when inhibiting (with an option to remember? )?
08:54jadahl: ofourdan: coud it be tabs vs spaces?
08:55ofourdan: ah I see it!
08:55ofourdan: ah nop
08:56ofourdan: but yes, 8-char tabs in rptocol, isn't it what we want?
08:56jadahl: iirc we use \t for tabs
08:57ofourdan: yeah. it;s what I used as well
08:58jadahl: I can see some places where you have 8 spaces though :o
08:58jadahl: ..the given surface
08:58jadahl: ....a protocol error "alr
08:58whot: ofourdan: summary="the wl_seat for which keyboard shortcuts should be disabled"
08:58jadahl: ...summary="the wl_seat fo"
08:58whot: has spaces
08:58jadahl: those three
08:58whot: only noticed it because it's different to the summary for "surface"
09:01daniels: xerpi: hi, good thanks but i really feel like i need another one which is actually more relaxing than having three weddings in one week :\
09:01daniels: xerpi: how about you? what are you up to these days?
09:02xerpi: oh wow that was intense then haha
09:02daniels: i've been working on modifiers stuff inside mesa, so not had time for atomic, and won't get to it at all until next week it seems
09:02daniels: yeah ...
09:03xerpi: daniels, I took advantage of the situation and almost fully wrote the entire project's document hehe
09:03daniels: xerpi: oh wow, nice! what's the plan? :)
09:03xerpi: I'm actually trying to check the fence status on commit to let the buffer be drawn or not right now
09:04xerpi: so my plan is to get some preliminary fencing working by the 12th this month
09:04xerpi: because at the 19th I've to deliver my project
09:04xerpi: I wish I could have helped more tbh
09:05ofourdan: to someone more competent on the topic for gnome-shell side of things)
09:05xerpi: but yeah, it being an end of degree project (a lot of documentation to do), and having two other subjects at uni doesn't help
09:06xerpi: so the IN_FORMAT blob support, fixing that fullscreen bug (took me a while to find the root problem), and if I can, adding some explicit sync support is everything I have done
09:11daniels: xerpi: no problem, you've helped plenty and it's definitely good work :)
09:12xerpi: maybe it's not enough to balance out the amount of time I've made you waste :')
09:17daniels: getting more people involved is definitely not wasted time!
09:18daniels: plus, you did find and fix a bunch of bugs
09:21jadahl: ofourdan: i'd uset he plugin class if you want to have mutter ask gnome-shell for things (look at MetaDialog or whatever it is called)
09:22ofourdan: jadahl: did you see I filed bugs to upload the patches for mutter and gtk+ (although it's lacking the key combo mechanism)?
09:23xerpi: daniels, true :)
09:24xerpi: so right now I've hooked up linux_explicit_synchronization_unstable_v1 from chromium os to Weston and added a client that uses this interface (weston-simple-egl-explicit-synchronization)
09:25xerpi: the compositor receives the fences from it just fine
09:25jadahl: ofourdan: i did see, but might not have time to look at them until next week or so
09:26ofourdan: oh, no hurry, those are just first draft, just to get something to discuss (and more importantly test)
09:26ofourdan: also this is in case I get hit by a bus, so they don't sit on my harddrive only .... :)
09:26daniels: xerpi: which is a great step :)
09:27xerpi: heh yeah
09:32ofourdan: whot, vrt each time vs. every time I found this: https://forum.wordreference.com/threads/each-time-every-time-or-whenever.917315/
09:32ofourdan: seems they are mostly interchangeable
09:33xerpi: daniels, that's some pseudocode I had in mind: https://hastebin.com/raw/ubumavujud
09:34xerpi: basically it defers applying to commit until the fence has been signaled
09:35xerpi: and if there's a wait pending and a new commit it requested, it drops the wait (mailbox)
09:36daniels: xerpi: aye, that sounds like the right thing indeed
09:38xerpi: good to know :P
09:39xerpi: I've actually implemented it but weston-simple-egl-explicit-synchronization's FPS also get into the compositor's FPS :/
09:39xerpi: I'm doing something wrong
10:41whot: ofourdan: miriam-webster also lists them as synonyms
11:41heeen: pq: around?
12:40pq: heeen, occasionally
12:41heeen: pq: I am seeing an issue with ivi shell on 1.9.1 or 1.9.0 where a weston_view has a null surface
12:42heeen: does it ring any bells? what is a good place to track this down?
12:42heeen: I can trigger it by launching an app with 2 surfaces, one on each screen I have, then closing it and launching it again
12:42heeen: looking for a patch to cherry-pick
12:43heeen: weston_view_create always takes a surface param to store in the view struct and I do not see null from there so it has to change at a later point
12:46pq: ofourdan, I see two accounts for you on bugzilla, which one should I CC?
12:47pq: heeen, nope, no recollection at all. You are sure you set the correct unique ivi-id for each surface?
12:47pq: heeen, although, I would assume ivi-shell to terminate the connection if you tried a non-unique ivi-id, so...
12:48ofourdan: pq: I think both should work, if work related, my rh email is preferable
12:53pq: ofourdan, it's free.fr and xfce.org, no redhat
12:53ofourdan: then definitely xfce.org :)
12:53ofourdan: I didn;t even remeber I had an account with free.fr
13:00pq: ofourdan, cc'd you on another xwayland feature request, just FYI :-)
13:00ofourdan: ah the xwayland scaling? hehe, no need I saw that earlier :)
13:01pq: yup, cool
13:02pq: several ideas and no clue which one(s) would work
13:04pq: I'm wondering if Xwayland dividing resolution by output scale would actually solve almost all mixed-dpi issues by forcing all X11 to be low-dpi... wait... does it not do that already?
13:04ofourdan: I don't think it does
13:04pq: How can it work if it doesn't do that? Does it scale input coordinates up to the output space?
13:06pq: if the X11 coordinate space matches... err... so what does it do on mixed-dpi? utterly confused? :-o
13:08ofourdan: I dont; see much code beingrelated to scale, output_handle_scale() is a no-op anyway
13:08pq: but it passes the wl_output mode list as is through to RandR?
13:09ofourdan: nope, it passes only one resolution, the current one
13:09pq: but, unscaled?
13:09ofourdan: I think so, yes
13:09ofourdan: I can try, real quick using mutter nested mode
13:09pq: is that also used for the screen size?
13:09ofourdan:has no hidpi screen
13:10pq: I mean, if you actually have a HiDPI output, you have, say, output scale = 2, then the space of input event coordinates will be just half of the claimed screen resolution in both dimensions
13:11ofourdan: so yeah, output scaling makes no difference for xwayland
13:12pq: and if a X11 client looks at RandR and makes window that big, it will actually be twice the size
13:12ofourdan: tested with "MUTTER_DEBUG_NUM_DUMMY_MONITORS=2 MUTTER_DEBUG_DUMMY_MONITOR_SCALES=1,2 mutter --wayland --nested"
13:13jadahl: pq: scaling xwayland windows has the issue when a window puts a popup menu relative to its window
13:13jadahl: pq: how do you move that? should you? when?
13:14ofourdan: we had some bug about xwayland in mixed dpi...
13:15pq: jadahl, I'm not sure I understand. The foundation is that all of X11 has a single global coordinate system, and that must be somehow mapped to the compositor's global coordinate system.
13:16pq: so probably the X11 coordinate system must be in the same scale as the compositor's global coordinate system, or in the scale of one of the output spaces
13:17pq: if wl_output.scale event is ignored in Xwayland, it implies that the X11 coordinate system must be in the scale of the compositor's global coordinate system.
13:17ofourdan: ah there!
13:17ofourdan: pq: bug 93315
13:18pq: no wait... I confused it
13:18ofourdan: oh, you commented in that bug as well :)
13:20pq: hmm, no, I didn't confuse it. Or I did, but... do you have any idea where I'm going?
13:21ofourdan: but your comment here still stands: https://bugs.freedesktop.org/show_bug.cgi?id=93315#c4
13:21pq: ofourdan, that's true, but I think there is an internal inconsistency in Xwayland now
13:22ofourdan: yet I don;t see any discrepancy in events using scale 2 (the x11 apps do not get scaled at all though)
13:23ofourdan: it all behaves as if scale was 1 for x11 apps afaics
13:23pq: so, Xwayland does not use buffer_scale so that is always 1. X11 window sizes are therefore in the same scale as the compositor's global space. But if output_scale=2, and you take the raw resolution from wl_output and show it in RandR, and application cannot make a window that big: it would be twice the size of the output when shown.
13:23ofourdan: I am not following ...
13:24ofourdan: is I use scale 1 on one monitor and scale 2 on another one, xrandr in xwayland reports both to be the same resolution
13:24pq: no no, just one monitor with scale=2.
13:24pq: let's not think about mixed-dpi yet, only hi-dpi
13:25ofourdan: it's the same
13:25ofourdan: the reported size is not scaled
13:25ofourdan: (I mean in xrandr)
13:25ofourdan: and the x11 window is not scaled either
13:25ofourdan: so it matches
13:25pq: The resolution advertised by wl_output is the physical output resolution. But if output_scale=2, then the actual desktop space (global coordinate space) is half of that, numerically.
13:25zubzub: ohhey pq is back
13:26pq: X11 clients draw with buffer_scale=1 because we have no way to communicate otherwise, therefore the X11 coordinate space is in the same scale as the global coordinate space.
13:27pq: also input is in the global coordinate space units
13:27pq: ofourdan, are you with me so far?
13:27ofourdan: x11 apps seems to be completely immune to scaling
13:27ofourdan: pq, for wayland native, I agree
13:27pq: ofourdan, that must be a mutter feature...
13:27ofourdan: oh possibly
13:27ofourdan: I haven;t tried with weston
13:28pq: weston does not set view scaling based on X11 coordinates
13:29pq: ofourdan, so, if an X11 app looks at RandR, gets the physical output resolution, and creates a window of that size, how does a user see that on the screen?
13:30ofourdan: as far as I can tell, under mutter, it's the expected output size
13:30pq: say, output resolution is 800x600, output_slace=2, an X11 app creates a 800x600 window, Xwayland commits the buffer with buffer_scale=1, the Wayland compositor scales it up to 1600x1200.
13:30pq: which one of the behaviours is better? :-)
13:31pq: and/or is there something wrong? :-)
13:32ofourdan: yeah, that's exactly the test case I am running here (the actual fake monitor size is 1024x768 in mutter) , but part of my misunderstanding is precisely that the x11 window is mot scaled up to double its size
13:32ofourdan: it's the "expected" unscaled size that is used
13:32ofourdan: or applied
13:34pq: is it expected? What about an X11 app that does *not* look at RandR, draws it's stuff at scale=1, and does not get scaled up - is it not unredably small now?
13:34SardemFF7: it would be the same for normal HiDPI X11
13:35pq: like, any windowed app that uses pixels as an absolute unit for sizes
13:36pq: It sounds like mutter's approach assume that all X11 apps are HiDPI aware, and weston assumes that none are. :-)
13:37SardemFF7: maybe because X11 assumes all are
13:37pq: except when they are not
13:38SardemFF7: but X11 doesn’t have the scale-them-up code anyway
13:38ofourdan: I am not sure I understand why you refer to xrandr for hidpi, the wl_output scale is notreported in xwayland's (fake) xrandr implementation - but X11 apps use a root property for hidpi iirc
13:38SardemFF7: so they look like crap, and why should they look good under Weston then? :-)
13:39pq: ofourdan, the inconsistency with RandR from my perspective is that if output_scale=2, RandR says the screen space is 800x600 when it actually is only 400x300 because the Wayland compositor will be scaling everything up.
13:40ofourdan: if we do that, it will break havoc in mutter I'm afraid :)
13:40pq: which then leads up to the question of mixed-dpi
13:40ofourdan: so we'd need a way to please both weston and mutte rapproaches
13:41pq: how do you keep everything legible in a mixed-dpi environment
13:41ofourdan: x11 won;t work in mixed dpi, that was the bug I pointed out
13:41ofourdan: I mean, it won't give a satisfactory result
13:41pq: it will work, if we force everything X11 to scale=1 and scale it up as necessary
13:42pq: everything will be legible on any dpi output
13:42ofourdan: didn't we consider that before?
13:42pq: maybe, I probably wasn't in that discussion, or I forgot
13:43ofourdan: it's a genuine question, I don't know if we did ...
13:43heeen: pq, who sets weston_view.surface apart from create_weston_view
13:43pq: it's trade-off between everything is guaranteed to be legible but something might be less pretty vs. good apps are pretty and the rest are illegible
13:43heeen: pq: if a client dies maybe? by way of a destructor listener?
13:44pq: heeen, mark the member with WL_DEPRECATED and compile ;-)
13:44heeen: just prefix itz?
13:44pq: heeen, suffix, just before the ,
13:44pq: heeen, suffix, just before the ;
13:45pq: ofourdan, damn it took long formulate my thoughts :-D But there it is, the trade-off.
13:46ofourdan: pq, then what about hidpi aware x11 apps, those which read the gsettings (such as gtk3), those would end up being scaled ... twice?
13:47ofourdan: (right, gtk3 should use wayland, but then we'll always have the odd one which cannot/don't want/hasn't been ported to use wayland native yet)
13:47pq: ofourdan, they would need to be configured to not scale up. Yes, it won't be pretty, but it will be legible. This is what I mean by pretty and legible.
13:48ofourdan: I reckon it would make sense
13:48ofourdan: dunno what others think (gtk and mutter devs)
13:49pq: I understand that if you are a distribution or a DE who only really supports the programs it chooses to, you can pretty well go for "good apps are pretty, let the rest be illegible", but generic projects like Weston would probably opt more for "make everything at least legible, if not pretty".
13:49pq: this seems to be forming into a preference question
13:52ofourdan: pq, for the bug you mention, I think it goes further than that. Many games use lower resolution and set the output to the desired resultion (using xrandr or xvidmode) so that the "window" is large enough - that won;t work on xwayland though
13:54pq: ofourdan, right, hence the suggestion to maybe use wl_viewport to scale up... hmm, but changing that on the fly won't work, positions will break.
13:55ofourdan: yeap, and teh scale is an integer which limits the possibilities
13:55pq: the output scale would work in the opposite direction, scaling the available modes list
13:58ofourdan: but if we allow x11 clients to change the scale, we'll end up with the same problems as we see with xrandr on x11, i.e clients "forgetting" to restore the original resolution (which would be scale in the case)
13:59ofourdan: and allowing x11 clients to do that is a bit unfair on wayland native apps :)
13:59pq: but that would be nothing new :-)
13:59pq: oh no no
13:59ofourdan: hehe, sure, but ...
13:59pq: I mean, the output_scale is dictated by the Wayland compositor, no X11 client could change that
14:00ofourdan: but then how do you solve the problem of an odd game wishing 640x400 so it looks fast?
14:01SardemFF7: "scaling up" is not slow
14:01pq: *if* the Wayland compositor assumes all X11 is scale=1 and scales it up per output as implied, then we should also divide the resolution exposed via RandR by output_scale to make it consistent with the rest of the coordinates in X11.
14:01SardemFF7: if the game is fullscreen, the Wayland compositor can scale it via (temp) modesetting if it sees fit
14:02SardemFF7: just like a Wayland fullscreen client
14:02pq: that would work for the bug report, because Xwayland and all X11 app would see a full-hd output while the actual monitor is HiDPI 4k and the Wayland compositor scales things up.
14:04pq: but it's a pretty limited solution, I agree. It won't help if the X11 app still needs to change the resolution.
14:04ofourdan: the game "asks" for a resolution it finds in the xrandr or xvidmode list of supported resolution, if there is only one (as of now) it will use only that one - So it means that xwayland must adverstise "false" lower resolutions that the client can pick from, the the compositor would automatically scale that, but based on what then?
14:04pq: so making RandR resolution changing work is orthogonal to using output_scale
14:05ofourdan: besides, I think some people would oppose to make xrandr resolutions changing possible
14:05pq: ofourdan, I will oppose if it was real, but I am fine with lying :-)
14:06pq: the question is, how could we implement the lie
14:06ofourdan: this is where I tend to get lost, because to me a good lie is pretty much the same as the real thing :)
14:07pq: so such luck here, I'm afraid :-P
14:07pq: RandR settings are X server wide, so it will affect all X11 apps, but that was given anyway already, so no worry about that.
14:09ofourdan: could we get away with something liks a window property?
14:09ofourdan: the xserver can set window proeprties, the x11 window manager reads them
14:10pq: RandR would essentially need to control a scaling setting in XWM applied to all X11 windows, there would be no other way to keep properly placed.
14:10ofourdan: (or am I just talking nonsense... I mean, not sure how that could help there)
14:13pq: ofourdan, thank you for the sparring, I don't think we can reach a conclusion today, it's fairly late for me already. This was an interesting excercise. Maybe someone gets an idea after a few nights sleep. :-)
14:14ofourdan: not an easy topic I'm afraid, nto the first time we scratch heads for that :)
14:14pq: it was certainly a revelation to me to hear about the different scaling scheme used in mutter
14:14ofourdan: how do you try the same with weston?
14:14ofourdan: (I mean, force a fake scale in mixed dpi?)
14:15pq: weston obeys the window sizes coming via Wayland protocol, and Xwayland never sets buffer_scale away from 1, so weston will automatically scale up according to output_scale.
14:16linkmauve1: I gave a try at implementing wp_viewporter into GLFW a few weeks ago, it basically gives arbitrary modes to any program using it to ask for fullscreen.
14:16linkmauve1: So far, aside from calculation issues with HiDPI mixed in, it’s been pretty much perfect.
14:17ofourdan: right, I see, weston scales x11 windows up
14:17ofourdan: everything looks bigger
14:17ofourdan: whereas mutter scales only wayland native apps
14:18pq: ofourdan, weston handles window management and input in the global coordinate space, which it assumes to be the same scale as the X11 coordinate space. So it all works just fine, assuming X11 apps never scale up themselves. The RandR resolution is in the wrong units though.
14:18ofourdan: reported resolution 3360x2048
14:18pq: and *that* was the inconsistency where I started the whole discussion from :-)
14:19ofourdan: I understand
14:19pq: I'm glad we finally came together, both ways :-D
14:19ofourdan: obviously if a client asks for a xwindow of that size, it won't fit once scaled
14:20pq: In the weston approach, all X11 apps are legible but none can be pretty. The bonus is that mixed-dpi works as well as any other dpi scenario.
14:23pq: sounds like we would need a new Xwayland option to control the RandR resolution scaling to make the weston approach internally consistent
14:24pq: does mutter deal with input in the output coordinate spaces rather than a single global coordinate space?
14:25ofourdan: I dunno
14:25pq: hmm, nevermind
15:40Shibe: how can I tell if my gnome session is running on wayland?
15:40Shibe: Xwayland appears to be running but weston-terminal wont launch
15:40Shibe: is there any way I can verify that it is running on wayland?
15:41SardemFF7: check if $WAYLAND_DISPLAY is set
15:42Shibe: SardemFF7: not there it seems
15:42Shibe: its just xwayland thats running
15:49heeen: pq: the crash I was seeing happens when a client connects and does not bind ivi-shell