06:48 pigonoid19: emersion: you are a clueless worm to me, with performance everywhere under the bar, except cowardish short cut abuse, you have no brain but toxin under the skull, you are scum to me. Do not interact with me, most people are scum to me, you are not anything different for some compassion to your soul freak.
06:52 pigonoid19: There is no ladies as cock suckers i am willing to share with such persons, and there is nothing i swallow as pride either, full statement is that you are scum to me
06:52 pigonoid19: that is it
06:54 pigonoid19: no composure or fungus or cells of your composure is not welcome near me, but yet you present yourself daily with abuse gifts, you get charged so, just fuck off from around me
06:55 pigonoid19: take your sluts with you who belived in you and admire you, and fuck off finally, or you get treated accordingly
06:56 pigonoid19: it is tyranny what you perform, you are going too far with this , i told you many times, you worm
07:00 pigonoid19: those channels are full of geniuses, cause the code done very well has reference to that, just at times people have to force themselves not to cheat to gain nothing on random persons terror
07:05 pigonoid19: like you realise what you are doing, how is the importance that you are better than me so deep, where as none believe you anyways, you act like a snitch , find some interests, and i may state something more relevant about you , if i reconsider, at the moment you are abusing scum to me.
07:08 pigonoid19: I get tired of smoking and ruining my health due to your awe, or arrogance or whatever that is, get yourself together finally, my uart project is delayed for days, cause i am nearly puking , or spewing , i do not understand what you organize.
07:09 pigonoid19: drunk as a skunk again in too many days, where i need to be working, you feel obsessed and happy to ruin me i imagine yes
07:10 pigonoid19: but it's not real persons interest
07:13 pigonoid19: you enjoy this don't you, so i left off from easydma decision, i compiled everything , but started to wonder wether i want the dma or interrupt driven uart, due to your actions i have been so inefficiently drunk for days to me it's not fun you see.
07:18 pigonoid19: i am afraid i missed some concept due added pressure, in real systems of defense and such related goals, i think interrupt driven is better and more secure a bit, people beam each other due to anger, and i would not want to expose that chaos
07:18 pigonoid19: if there is some concept of defense in commodity hw, which can be real i think i do not want easydma to be exposed as option
07:22 pigonoid19: otherwise the renode and zephyr work and those german norwegian made slides were all good and code is good, it's offered still, but yes i think i will try the interrupt driven, obviously easydma performs the best for sure on bursts, i see that custom one as a danger to myself again
07:27 pigonoid19: I am not giving up cause the complexity of the solutions, i am giving up on hope cause they do things that are not allowed by law, such as beaming my organs and brain so i would be more senseless and less of an issue as dead
07:30 kchibisov: pq, jadahl, emersion, daniels
07:31 pigonoid19: kchibisov: good bye mindill person, i have experience with your abuse, and this wireless signal i have gotten before that totally mindill bloke targets my organs through my own equipment
07:32 pigonoid19: due to anger on some pornography went bad or some sexual relations and spewing ones misfortune at me
07:32 kchibisov: Ah, a bot, I guess.
07:36 pigonoid19: but interrupt driven one has the same vulnerability not the same, but also simple way to intrude, and safety code is more than only compilation
07:37 pigonoid19: so i started thinking perhaps i should give up and vanish, cause i do not have momentum or time to get all the safety to get into testing
07:43 pigonoid19: it's easier to vanish, mom is going to sell the apartment anyways, and try to accomplish that later by not showing my location and logging to networks, so i think i delay with that mission, however i bought the required micro controllers, no ble, it just nordic has a proper driver to use silicon labs cp2102 to get the console in hw, someone named tyler hoffman
07:44 pigonoid19: wrote a blog about it, and implemented all the code
07:48 pigonoid19: so to get that shell to operational no code is additionally required, you need a device node which zephyr arm board of nordic links in, and use micropython to handle the communication
07:48 pigonoid19: i looked and did all the testing, but safety code requires my lines also to me tested
07:49 pigonoid19: renode runs that on x86 and has the zephyr realtime os device tree node a pseudo tty to talk with, this is fw shell
07:49 pigonoid19: it's actually very good idea, and the work is good
07:49 pigonoid19: by tyler
07:50 pigonoid19: technically it is not possible under linuxes driver, it used to be though, but current driver does not allow that functionally
07:50 pigonoid19: and they use realtime os for such needs, which is also very correct way or movement
07:50 pigonoid19: it's realtime os is emulated with posix interrupts
07:52 pigonoid19: that guy is claiming to be founder of memfault , i mean likely is also :)
07:53 pigonoid19: that is a region hack method to get jtag and uart debuggers and such gdb sessions over CM of arm processors
07:55 pigonoid19: so in his blog entry with the help of renode, it should be possible to get to x86 computer instead of arm too
07:56 pigonoid19: which is kind of desired when in the bunch of hyenas surrounded who attack you all the time
08:02 pigonoid19: this is very valuable asset to the maintainers, for an example the hotel on the island was so badly attacked, that rectifiers gave up etc. cause some beamed at the logic in anger
08:02 pigonoid19: so it's very difficult to open all the time the casings and is nightmare in such circumstances where evil has to be faught with
08:05 daniels: kchibisov: thanks
08:05 kchibisov: np.
08:08 daniels: dottedmag: and no problem about xkb, I’m busy today but I’ll ping you during the week
12:04 DodoGTA: What's the right way of detecting a keyboard layout on Wayland?
12:07 kennylevinsen: DodoGTA: by listening to the wl_keyboard keymap event which contains the keymap
12:08 kennylevinsen: you then load that into xkbcommon and you're all good to interpret keycodes
12:09 kennylevinsen: as a random note, I'm not entirely sure why we need the modifier event - I feel like the key event and keymap contains everything the client needs...
12:19 ifreund: kennylevinsen: isn't it something about communicating modifier state at the time of keyboard enter?
12:20 ifreund: I vaguely remember someone explaining a reason to me at some point in the past but don't remember the details
12:21 kennylevinsen: Well enter includes the keys held. Having modifiers in a separate event won't help you know if "a" was originally pressed before or after the modifier, so it doesn't seem to provide more info than what can be deduced from the modifier key being in the enter list...
12:23 kennylevinsen: all you know is if a modifier is active *now*, which you can also see from it being on the enter list...
12:23 kennylevinsen: Maybe I'm missing something - just seems redundant at first glance
12:24 kennylevinsen: And I don't think my compositor would need libxkbcommon itself if it didn't have to track the modifiers
12:38 swick[m]: JoshuaAshton: I think for windows apps rec2020 is fine for scRGB but the wayland protocol makes this metadata which implicitly exists somewhere in windows explicit
13:54 zamundaaa[m]: kennylevinsen: see https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/259 for a use case for the separate modifier event
13:55 kchibisov: kennylevinsen: 1st, you shouldn't assume that something is pressed based on latched keys in enter. 2nd modifiers change should have an explicit ordering, such as, after the key, so you can press Shift + Shift to change layout, if you emit the event before key, you won't be able to do so. 3rd The meaning of what is modifier could be different, you have sticky keys and such. 4th you can have the event without keyboard focus at all for mouse inp
13:55 kchibisov: ut.
13:57 kchibisov: But that's what I remember/know over the years in writing windowing stuff, so take it with the grain of salt.
13:59 kchibisov: I think the ordering is important, so the clients have less confusion on how to handle modifiers changing. Because every event which could result in modifiers event(enter, key) says that 'modifiers must be after'.
14:04 kennylevinsen: Hmm I guess latching modifiers wouldn't be covered by checking held keys yeah
14:04 kennylevinsen: zamundaaa[m]: good point, forgot that MR
14:08 kchibisov: kennylevinsen: you also need an xkb in your compositor if you plan on having bindings.
14:12 kchibisov: Unless you have a proxy compositor ofc.
14:14 kennylevinsen: my compositor doesn't have bindings itself - currently offloaded to a manager client, maybe to a plugin instead soon
14:15 kennylevinsen: not that it's a huge issue that it has libxkbcommon, just felt silly to call out to *just* for modifier tracking
14:15 kchibisov: In general compositors have bindings and you have xkb_variant setting for weird layouts.
14:18 kennylevinsen: hmm I still need it for look up the keymap to read, so wouldn't be able to avoid it anyway
14:18 kchibisov: yeah, you need keymap + other settings reading.
14:23 kennylevinsen: not really, just need to load the keymap, settings go into that load. Then I have what I need for the keymap events. From there all I am using xkb for is modifier tracking.
14:24 kennylevinsen: I already have a working compositor, just felt like I was doing a silly amount of work to track modifiers if they could technically be avoided - but I guess there are a few cases where they can't
14:38 ifreund: hmm, is mpv's resize behavior not technically a protocol error? If I try to resize it along only the x-axis it grows along the y-axis as well to maintain aspect ratio
14:39 ifreund: however, that growth along the y-axis extends beyond the height requested by the compositor
14:39 ifreund: > The window geometry specified in the configure event is a maximum; the client cannot resize beyond it. Clients that have aspect ratio or cell sizing configuration can use a smaller size, however.
14:41 ifreund: Perhaps the protocol is a bit too strict here, I'm not sure how else a client could be expected to grow in size while maintaining an aspect ratio
14:43 daniels: kennylevinsen: not just latching but also locking modifiers
14:47 kennylevinsen: ifreund: in which state? That text is for the "resizing" and "fullscreen" top-level states, and if set then yeah it should reduce rather than grow to fit
14:47 ifreund: kennylevinsen: I set the resizing state during interactive resize, which is when mpv exhibits this behavior
14:49 ifreund: Like I said though, I think the protocol's wording is too strict here if it intends to allow growing clients that maintain a fixed aspect ratio though
15:00 zamundaaa[m]: ifreund: the protocol isn't too strict, the client is supposed to keep the aspect ratio inside the bounds given by the compositor
15:03 ifreund: zamundaaa[m]: that would mean that the client can't make the window larger unless the compositor happens to send a larger configure matching the aspect ratio
15:03 zamundaaa[m]: no, it does not need to match the aspect ratio
15:04 ifreund: zamundaaa[m]: how would it be possible for resizing along only the x-axis to work?
15:04 zamundaaa[m]: ifreund: the window will simply stay the same size
15:05 zamundaaa[m]: It's up to the user to resize it also along the y axis if they want a window with fixed aspect ratio to be bigger
15:05 ifreund: the y axis has the exact same problem though
15:06 zamundaaa[m]: To be frank I don't understand where you see a problem?
15:06 ifreund: the only way for the window to grow would be for the user to resize both axes in a way that maintains the aspect ratio
15:07 ifreund: zamundaaa[m]: the problem is that doing that as a user will be incredibly finnicky
15:07 ifreund: since the compositor is not aware of the aspect ration
15:07 zamundaaa[m]: The compositor does not need to make the size match any aspect ratio
15:07 ifreund: and resizing generally happens across many tiny incremental configures
15:08 zamundaaa[m]: The client is supposed to choose the biggest size that fits inside the configure bounds
15:09 ifreund: it may be the case that the client fits in the cumulative bounds of the many configures which each have a small change in size
15:09 zamundaaa[m]: Maybe it would be simpler to understand if you just try a client with the correct behavior. like Firefox with the picture in picture window for example
15:11 ifreund: zamundaaa[m]: what firefox version? mine seems to paint black bars on the top and bottom of the video to maintain aspect ratio
15:11 zamundaaa[m]: I'm on 112
15:11 ifreund: same
15:12 ifreund: https://0x0.st/HP9I.png
15:13 ifreund: the point is that an interactive resize isn't a single configure, it's many smaller configures each of which the client may not grow beyond
15:15 ifreund: so the client cannot commit a larger intermediate buffer for the interactive resize for these smaller configures unless they happen to manitain aspect ratio
15:15 zamundaaa[m]: no, it is not smaller configures. It is one absolute size limit
15:15 zamundaaa[m]:uploaded an image: (479KiB) < https://matrix.org/_matrix/media/v3/download/kde.org/d12a88af3d3201b2fd73b85cafcb41873d7c7567/Screenshot_20230430_171421.png >
15:16 zamundaaa[m]: If I go to the right with the cursor, the PiP window will be limited by the height. But if I also go towards the bottom with the cursor, then it can grow
15:16 ifreund: what compositor?
15:16 zamundaaa[m]: KWin
15:17 ifreund: and firefox is 100% not running through xwayland or something?
15:17 ifreund: just trying to figure out why the behavior is different for the same version
15:23 zamundaaa[m]: yes
15:40 zzag: is the behavior different when XDG_SESSION_DESKTOP=KDE is set?
15:49 ifreund: zzag: it does indeed, wtf
15:56 ifreund: zamundaaa[m]: firefox's picture-in-picture window appears to consider the size it had when the resize was started to be the maximum, not the latest configure
15:57 ifreund: i.e. it lets you grab the right edge, make the window smaller, and then make it bigger again up to the starting point
15:58 ifreund: (testing under weston with XDG_SESSION_DESKTOP=KDE set
15:58 ifreund: also it has artifact (black bars) along the resize edges during the resize
15:59 ifreund: I definitely wouldn't hold this up as an example of a client behaving perfectly
16:03 zamundaaa[m]: That's not the behavior I see, not even under Weston
16:03 zamundaaa[m]: Bugs like that are probably the reason why it's not doing that on Weston by default though
16:07 ifreund: oh, I might have a really old weston version
16:08 ifreund: 9.0.0 isn't that old I guess
16:10 zamundaaa[m]: I'm on Weston 11.0.1
16:21 ifreund: zamundaaa[m]: I get the same behavior I saw on weston 9.0.0 on weston's current main branch
16:22 ifreund: black bars along the bottom and right edges during resize
16:23 ifreund: and restricted to the size at the start of the resize rather than the latest configure when resizing from only one edge (not a corner)
16:24 ifreund: Can KWin be launched without logind these days?
16:41 zamundaaa[m]: You can start it from the tty
21:38 jim: following quote from https://wayland.freedesktop.org/ : "Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. Weston can run as an X client or under Linux KMS and ships with a few demo clients." My question is brief, I know you're a dev community, so I won't be making other noise. My question is: what is linux KMS
21:38 jim: '?
21:40 soreau: KMS = kernel mode setting
21:40 soreau: it basically means using the drm backend
22:01 emersion: jim: it's the kernel API to get pixels on screen
22:12 jim: emersion, thanks for response.... oh ok, what does KMS stand for?
22:46 pac85[m]: <jim> "emersion, thanks for response......" <- Kernel mode setting