03:09 uniqdom: Hello, I'm new here, trying Wayland by using Weston in X11. Is there a way to share the clipbard between Weston and X11 apps?
03:18 soreau: uniqdom: you can, if the x11 apps run through xwayland in the weston session
03:20 soreau: but to share as you're describing, that is something that isn't implemented AFAIK
03:20 uniqdom: soreau: I see.
03:21 uniqdom: can you also copy and paste with mouse?
03:21 soreau: highlight/middle-click to copy/paste?
03:22 uniqdom: yes
03:23 uniqdom: does that have a name? because it is different than the clipboard, I think
03:23 soreau: it works in wlroots compositors, not sure about weston, you'd have to try it yourself
03:25 uniqdom: ok. I'm really new here in wayland. I just wanted to test waydroid (and android vm). Wayland was a requierement, and I still had x11 in my system.
03:26 uniqdom: I will have to dig a bit what is wlroots
03:28 uniqdom: Thanks soreau, have a good day/night
11:25 pq: SardemFF7, I just noticed Gitlab telling me that a webhook in Weston was disabled after being retried multiple times. Does that mean anything to you?
11:26 SardemFF7: hum, is there a time for the fails?
11:26 pq: not really, I noticed the error banner just now
11:27 pq: no idea of any logs or anything
11:28 daniels: yeah, I've seen it periodically - connecting to the remote host times out
11:28 SardemFF7: in the webhook config, you can click on the webhook and see the history I think
11:29 pq: Doesn't seem to work that way. There are only buttons "test", "edit" and "delete".
11:31 SardemFF7: on the “edit” page?
11:32 pq: ah, there is the log. I didn't dare "edit" at first. :-)
11:33 pq: 1 day ago, Error: Net::ReadTimeout
11:34 pq: Jan 12, 2023 11:36am GMT+0200
11:41 SardemFF7: thanks, checking
11:43 pq: mjt, I'm curious, what does your keyboard manufacturer say about remapping on Linux (and not in the hardware)?
11:44 pq: mjt, I'm also curious about those Weston bugs, whether we know about those yet.
11:46 mjt: pq: I'm not sure I follow (re keyboard remapping). They suggest using standard tools to do that, either gui or setxkbmap or whatever. Most of the discussions seems to be about the layouts, which one is better and why
11:47 pq: mjt, setxkbmap is X11, IIRC. What other tools do they suggest? I'm not aware of any standard tools.
11:48 mjt: I'm not yet there. I do remember though that something quite similar to X11 keyboard definitions were used for linux console too
11:48 pq: I'm not sure about the console, but Wayland compositors use the exact same layout etc. files as Xorg.
11:49 pq: That's what xkbcommon implements, and pretty much all Wayland compositors use.
11:49 mjt: keyboard(5) suggests: setupcon(1), ckbcomp(1), console-setup(5), loadkeys(1), kbdcontrol(1)..
11:50 pq: none of those are relevant for Wayland compositors, I believe
11:50 mjt: I'll look at all this later. THere's one annoying thing on this kbd which I'll have to fix anyway. I just had no time for that
11:52 mjt: (the thing is that it doesn't have Ins key, instead it is Fn+Del, and it turned out I do use Shift+Ins quite a lot. On the other hand, right next to this Del they've PrtScrn which is useless but can be remapped to Ins. It even has the right label)
11:53 pq: https://github.com/swaywm/sway/wiki#load-a-modified-custom-xkb-keymap-xmodmap-equivalent is probably the hint emersion referred to.
11:53 mjt: speaking of wayland issues, I don't know if these are due to freerdp or wayland. For one, Xfreerdp (yes it's X, ie, working with xwayland) can't run in fullscreen mode
11:53 mjt: s/wayland/weston/
11:54 mjt: this is with latest weston, it worked before
11:55 pq: oh, a regression, that would be really nice to report
11:55 mjt: with latest weston and current xfreerdp2, the fullscreen window is offset by the size of the waybar
11:55 pq: waybar on weston?
11:55 mjt: no
11:55 mjt: err. I tried them all in sequence, and each had their own issues, I'm confusing them now :)
11:55 pq: heh
11:56 mjt: weston, sway, cage, something else...
11:56 pq: anyway, the keyboard remapping works by writing a layout file, and then pointing your compositor to that instead of a standard layout, I believe.
11:56 mjt: there's the bar at the top of weston screen. xfreerdp /f does not cover that one, instead it is *moved* by that size down and *right*, keeping the same size
11:57 wlb: weston Merge request !1113 opened by Loïc Molinari (molinari) gl-renderer: Improve GPU profiling accuracy https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1113
11:57 wlb: wayland Merge request !288 opened by Marius Vlad (mvlad) release.sh: Make use of workaround to allow upload of other assets https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/288
11:57 mjt: so bottom and right sides of the window are off the screen
11:57 pq: moved down because of the panel is what happens when maximized and it shouldn't happen for fullscreen, but moving also *right* make me thing it's not the panel's doing.
11:58 pq: *think
11:59 mjt: I haven't looked very closely because instead of 3..5 days this project took 3 months (with numerous combinations of software)
11:59 pq: since the app is running through Xwayland, this is probably an XWM bug in Weston.
12:00 mjt: so after trying new weston briefly, seeing this issue, I didn;'t dig in but moved on instead
12:00 pq: right, understandable
12:00 mjt: freerdp has wayland version. but due to previous bug in weston they changed quite some code in wlfreerdp
12:01 mjt: and it is not complete anyway
12:02 mjt: now when this thing *finally* works "somehow" (I ended up returning to ol'good Xorg entirely, and writing some glue in C - surprisingly there's no x idle program which actually works ;) - I had to write one), I now have some time to do debugging
12:03 SardemFF7: [about the webhook] that’s really weird, it seems that some buffer just fills itself and is not read anymore and when I restart it all gets read at once, I’ll have to do some load testing to figure it out I guess
12:05 mjt: (but I also have to catch the other stuff up too)
12:06 pq: SardemFF7, ok, thanks
12:07 mjt: pq: issue initially reported against freerdp which turned out to be weston issue: https://github.com/FreeRDP/FreeRDP/issues/6722 (I wrote about that at the end of that long page) - but while debugging it, we found various "fun" stuff in wlfreerdp who uses mouse coordinates in a wrong way..
12:08 mjt: I probably can bisect the fullscreen mode regression
12:12 pq: that would be nice :-)
15:36 mjt: pq: bisecting seems to be a bit difficult due to interdependencies..
15:36 mjt: how xwayland and weston relate to each other?
15:45 ManMower: mjt: hmm, that issue 6722 is hard to follow and messy, but at the end the quoted weston patch isn't what fixed that problem. freerdp commit 5b09cd57a7 probably did, as it does what gschwind suggested (stop setting the cursor hotspot wrong)
15:45 mjt: ManMower: yes it's messy as it hit multiple people and everyone tried to help :)
15:46 mjt: ManMower: the thing is: after 5b09cd57a7 it didnt work still
15:46 ManMower: what is "it"?
15:46 mjt: wlfreerdp. it still had that mouse pointer issue
15:47 mjt: jumpy mouse
15:47 mjt: but when switching weston from 10.0.2 to 10.0.3 (or is it 10.2=>10.3?) the problem disappears
15:47 ManMower: O.o
15:47 mjt: regardless of 5b09cd57a7
15:48 ManMower: but those patches are for weston's test clients
15:48 ManMower: not weston's cursor handling
15:49 mjt: I especially built two versions of weston when someone here said 10.0.3 has the fixes
15:49 ManMower: can you give me a quick way to reproduce this bug?
15:49 ManMower: I have windows machines on hand if that's necessary
15:50 mjt: heh. I'm tryin to setup a testbed with weston here currently
15:51 mjt: the prob was rather trivial to reproduce when run on weston directly (without additional compositor like gnome)
15:51 mjt: any mouse click in the remote freerdp window and the cursor goes off
15:52 mjt: with 5b09cd57a7, I *think* (I too am confused now by all that already), the cursor after click were *moving* to the edge of the remote desktop in diagonal direction
15:53 mjt: like animation
15:53 mjt: it stopped with weston 10.0.3
15:53 ManMower: do you build freerdp yourself?
15:53 mjt: I tried it too when debugging
15:54 ManMower: (because if you do, maybe you can save me time figuring out what cmake options I need to enable the right clients and what not...)
15:54 mjt: I built both freerdp and weston
15:54 mjt: it builds with everything by default iirc, but needs the right build-deps
15:55 mjt: if your distro have freerdp 2.8 or later it should be enough already
15:56 mjt: 2.9 (current) had other issues with wlfreerdp (mentioned in my message at the end of 6722)
15:57 mjt: it'd be really great if you two (freerdp and wayland people) work together on this. They tried really hard to figure it out. I'm just a user (with strong programming expirence but not in these areas)
15:58 mjt: I'm trying to figure out what to do with the misplacement of xfreerdp window within current weston right now
15:59 mjt: but it looks like i'll have difficult time with these :(
16:00 ManMower: looks like 2.8 is almost certain to have the cursor problem because the freerdp fix for it landed after 2.8.1 was released?
16:00 mjt: yes
16:00 ManMower: k
16:00 ManMower: I'll try newer.
16:00 mjt: I tried 2.9 (last) freerdp
16:01 mjt: with weston 10.0.1 and with weston 10.0.3 - for *sure*, but can't say with 100% certainity about 10.0.2
16:01 mjt: still have local build of 10.0.3
16:04 mjt: the puzzling thing about this issue was that it (almost) never happened with other compositors (eg neither gnome/mutter nor sway). "Almost" because some reported it can be seen under gnome too
16:07 mjt: btw, why dialog(1) does not show box characters in weston terminal? does the term implement switching to box drawing?
16:07 ManMower: weston-terminal isn't something you should be using for anything beyond testing a copositor.
16:07 ManMower: stick to the "real" terminals. weston-terminal is a broken toy.
16:07 mjt: I see
16:08 mjt: I think it's good enough to run some simple command (like freerdp)
16:08 ManMower: to more directly answer your question, it's because weston-terminal isn't a very good terminal. :)
16:08 ManMower: yes
16:08 ManMower: but trying to use it as a daily driver will be painful :)
16:10 mjt: it could also be that I was tired when testing 10.0.3 + mouse in wlfreerdp, and haven't noticed something which made my test void. It's unlikely but possible.
16:12 ManMower: hmm, I just get a flash of display then the client disconnects.
16:13 daniels: at a guess, that'd be ack_configure mishandling
16:13 ManMower: "Closed from Wayland"
16:14 ManMower: looking at the log, yeah, probably ack_configure
16:16 mjt: with freerdp 2.9 and weston 10.0.1 the bug with mouse position is definitely there
16:16 mjt: just verified
16:17 mjt: there's also another issue with mouse cursor: it does not change - when hovering over window borders, over text input areas where it should become ][-bar, etc
16:18 ManMower: that's probably because the patch that fixes it (5b09cd57a7) is apparently not in a release yet
16:19 ManMower: yeah, I can't even get this to connect, so I'm not going to be much use debugging cursor problems. could be something in my local setup.
16:20 mjt: which freerdp version did you try?
16:20 ManMower: git master
16:21 mjt: oh.. they just switched to sdl2
16:21 mjt: 2 days ago. it is bumpy :)
16:21 ManMower: 2.8 actually connects
16:22 ManMower: but doesn't bother to decorate the rdp window
16:23 mjt: it's barebones wrt decorations
16:32 ManMower: well, I can reproduce the bug on 2.9 even with the patch that I thought should fix it cherry-picked.
16:33 mjt: heh
16:33 mjt: I was about to say the same thing :))
16:33 mjt: just built 2.9 with that patch and run a test :)
16:44 mjt: < mvlad> weston 10.0.3 had some hot spot cursor fixes, if testing w/ latest should also be there.
16:44 mjt: that's where I got this info
16:45 mjt: on Dec-29
16:50 ManMower: oh, I wasn't running what I thought I was. heh.
16:50 ManMower: I'm not actually seeing that bug in windows paint
16:50 ManMower: silly question... you're not running weston in a virtual machine, are you?
16:51 mjt: I tried in various
16:52 mjt: right now it is qemu with qxl
16:52 mjt: the same thing happens on bare metal
16:52 ManMower: are you certain? because in some virtual environments cursor hotspots aren't handled properly
16:53 ManMower: and gnome is probably more sensible at noticing this is the case than weston
16:53 mjt: Hi akallabeth[m]
16:54 mjt: this is the freerdp guy :)
16:54 ManMower: hopefully the matrix bridge is working today
16:55 mjt: well, lemme test on a baremetal just to be sure
16:55 ManMower: thanks
16:55 mjt: it'd be interesting to fix the hotspot position in qemu too, if you have some more info about that
16:55 ManMower: that's a bigger deal
16:57 mjt: (I had to switch from stdvga to qxl due to something else required by wlroots now but not supported in stdvga; myself, I come from qemu land, being one of its developers)
17:01 mjt: yes it definitely happens on bare hw
17:01 mjt: very well wisible in paint
17:02 ManMower: using which weston and freerdp versions?
17:02 mjt: it is 10.0.1 and 2.9 right now. trying with uwc patch now..
17:02 mjt: it looks *exactly* like in qemu
17:04 mjt: on baremetal, the cursor changes properly within wlfreerdp window. While in qemu it does not
17:05 mjt: ok. 5b09cd57a7 definitely fixes some probs with the cursor
17:06 mjt: but some of them remains, and they're quite similar to this offset one
17:07 ManMower: what remains? I can't see anything wrong just moving the mouse around in windows paint
17:08 ManMower: (on weston 10.0.1 here)
17:09 mjt: like right now, after some clicking, the draw dot in paint which should be in the center of the mouse "cross" cursor, is off by a few pixels - diagonally to up-left. But the "vertical window resize" cursor (two arrows up-down) is off down to about 10 pixels
17:09 mjt: after moving it to top-left corner (trying to move below that) things cyncronises
17:09 mjt: (sp)
17:10 mjt: it's enough to drag paint window (clicking at the title bar and moving just a bit) to trigger that again
17:11 mjt: s/below/beyong/ - something's wrong with my English today :)
17:13 mjt: actually the vertical resize arrow cursor is always off by about 10 pixels
17:14 ManMower: I get all sorts of spastic cursor behaviour without the uwc patch...
17:15 ManMower: oh, there's a wrong hotspot now
17:28 mjt: it definitely had become better with freerdp uwc patch
17:29 mjt: but it looks like I just didn't try hard enough with weston 10.0.3 to reproduce the remaining issues
17:30 ManMower: mjt: looks like a freerdp bug, they're using the wrong serial for pointer_set_cursor.
17:30 mjt: akallabeth[m]: ping? :)
17:30 ManMower: looks like they're updating it on mouse click instead of just on pointer enter events
17:31 ManMower: so as soon as you click anywhere in the rdp window you've set yourself up for broken cursor hotspots until you exit/enter the window
17:31 ManMower: at which point it'll work again
17:32 ManMower: could just try removing the seat->display->serial = serial; in pointer_handle_button() in uwac-input.c as a quick test...
17:32 ManMower: err, no, needs a deeper audit. they update that on keystrokes too
17:33 ManMower: so your cursor hotspot changes will break after a keystroke I guess.
17:34 ManMower: https://gitlab.freedesktop.org/wayland/wayland/-/blob/master/protocol/wayland.xml#L1909 relevant wayland protocol doc. the serial is expected to be from the *enter* event specifically
17:35 ManMower: other compositors may handle this differently I guess, but weston's behaviour is correct
17:35 mjt: yes hotspot is off once I click any key on keyboard
17:35 mjt: I never tried that
17:36 ManMower: looks like display->serial is only used for hotspots though
17:36 ManMower: so just remove all setting of it that doesn't come from an enter event
17:36 mjt: (just had this combo - weston + wlfreerdp - freeze on me, had to kill weston logging over network - guess the weston's idle timer triggered)
17:37 mjt: the monitor went blank and no clicking or touching keyboard turned it back on until I pkill weston
17:37 ManMower: that's surprising. unless weird VM viewers are involved. vmware's removes the mouse device on display sleep, so you can never wake it with the mouse
17:38 mjt: it is baremetal with nothing but weston and wlfreerdp
17:38 mjt: run from linux tty
17:38 ManMower: interesting. not sure what's breaking there then.
17:38 mjt: and weston-terminal ;)
17:38 ManMower: k, freerdp hotspots seem to work for me now, with all the broken input->display->serial updates removed
17:40 mjt: heh. it just did it again, turning screen off :)
17:41 ManMower: what's your gpu?
17:41 mjt: Intel(R) Celeron(R) N5105 @ 2.00Ghz
17:41 mjt: i915
17:42 mjt: it's a small testing machine
17:42 ManMower: surprised to see trouble on that
17:43 mjt: the monitor isn't off, it is just all-black. when the idle timer triggers, it's usually turned off (dpms, whatever it is)
17:44 mjt: started weston with --debug, let's see..
17:44 ManMower: I'm not going to have time to chase that right now, but if you need a work around you can just turn off the blanker I guess. heh :(
17:45 mjt: I'll have to test with 11.0 first anyway
17:45 mjt: (hopefully debian bookworm will come with that one)
17:46 mjt: ManMower: thank you very much for the debugging session and finding the hotspot issue! it's been a long and bumpy ride :)
17:47 ManMower: np. hopefully the rest of your journey is smoother. :)
17:48 mjt: I'll have a bit more time once this project (which took 3 months instead of 3 days) is complete, so I'll do some debugging too, hopefully, for the rest of the issues I faced
17:52 mjt: lol. and the qemu machine I left running also switched to "idle state". With all the windows in BRIGHT RED COLOR (various shades of it). Once I moved mouse over it, it switched to the usual weston's [Unlock your display] dialog with green circle inside
17:53 ManMower: yeah so the bright red thing is probably https://gitlab.freedesktop.org/mesa/mesa/-/issues/8072
17:53 ManMower: assuming you're running bookworm and using llvmpipe to render
17:53 mjt: bookworm it is, yeah
18:08 mjt: ..and ofcourse the lockup isn't happening with --debug!.. :))
18:08 mjt: remove --debug and it locks again
19:08 paulk: pq: hey, you worked on mmiotrace right?
19:09 paulk: I'm looking to use something like that on arm
19:09 paulk: as far as I could see it involves having a page fault and decoding the instruction from ip to get what the read/write is
19:09 paulk: what I don't see is where the I/O actually happens
21:14 paulk: I see "The page is marked present and the page-faulting code is single-stepped to execute the instruction doing MMIO"