ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
shoragan has quit [Quit: quit]
shoragan has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #wayland
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
tjaden has quit [Quit: leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
Fxzxmic has joined #wayland
realguy1 has joined #wayland
realguy1 has quit [Remote host closed the connection]
dcz has joined #wayland
floof58 is now known as Guest34
floof58 has joined #wayland
Guest34 has quit [Ping timeout: 480 seconds]
gspbirel568400849879091923661 has joined #wayland
pigonoid19 has joined #wayland
floof58 is now known as Guest35
floof58 has joined #wayland
gspbirel56840084987909192366 has quit [Ping timeout: 480 seconds]
Guest35 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
fmuellner has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<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.
<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
<pigonoid19>
that is it
<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
<pigonoid19>
take your sluts with you who belived in you and admire you, and fuck off finally, or you get treated accordingly
<pigonoid19>
it is tyranny what you perform, you are going too far with this , i told you many times, you worm
floof58 is now known as Guest45
floof58 has joined #wayland
<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
Guest45 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<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.
<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.
fmuellner has quit [Ping timeout: 480 seconds]
<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
<pigonoid19>
but it's not real persons interest
<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.
<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
<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
<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
<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
<kchibisov>
pq, jadahl, emersion, daniels
<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
<pigonoid19>
due to anger on some pornography went bad or some sexual relations and spewing ones misfortune at me
<kchibisov>
Ah, a bot, I guess.
<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
<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
<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
<pigonoid19>
wrote a blog about it, and implemented all the code
<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
<pigonoid19>
i looked and did all the testing, but safety code requires my lines also to me tested
<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
<pigonoid19>
it's actually very good idea, and the work is good
<pigonoid19>
by tyler
<pigonoid19>
technically it is not possible under linuxes driver, it used to be though, but current driver does not allow that functionally
<pigonoid19>
and they use realtime os for such needs, which is also very correct way or movement
<pigonoid19>
it's realtime os is emulated with posix interrupts
<pigonoid19>
that guy is claiming to be founder of memfault , i mean likely is also :)
<pigonoid19>
that is a region hack method to get jtag and uart debuggers and such gdb sessions over CM of arm processors
<pigonoid19>
so in his blog entry with the help of renode, it should be possible to get to x86 computer instead of arm too
<pigonoid19>
which is kind of desired when in the bunch of hyenas surrounded who attack you all the time
<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
<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
gspbirel5684008498790919236617 has joined #wayland
kts has quit [Quit: Konversation terminated!]
pigonoid19 was kicked from #wayland by ChanServ [You are not permitted on this channel]
<daniels>
kchibisov: thanks
<kchibisov>
np.
Fxzx_mic has joined #wayland
<daniels>
dottedmag: and no problem about xkb, I’m busy today but I’ll ping you during the week
Fxzxmic has quit [Ping timeout: 480 seconds]
gspbirel568400849879091923661 has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
kts has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
rasterman has joined #wayland
fmuellner has joined #wayland
rtjure has joined #wayland
paulk has joined #wayland
clem_ has quit [Quit: clem_]
fmuellner has quit [Ping timeout: 480 seconds]
clem_ has joined #wayland
clem_ has quit []
clem_ has joined #wayland
kts has quit [Quit: Konversation terminated!]
jmdaemon has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Read error: Connection reset by peer]
clem_ has quit [Quit: clem_]
clem_ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
clem_ has quit [Quit: clem_]
clem_ has joined #wayland
clem_ has quit []
clem_ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
<DodoGTA>
What's the right way of detecting a keyboard layout on Wayland?
<kennylevinsen>
DodoGTA: by listening to the wl_keyboard keymap event which contains the keymap
<kennylevinsen>
you then load that into xkbcommon and you're all good to interpret keycodes
<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...
<ifreund>
kennylevinsen: isn't it something about communicating modifier state at the time of keyboard enter?
<ifreund>
I vaguely remember someone explaining a reason to me at some point in the past but don't remember the details
<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...
Fxzxmic has joined #wayland
<kennylevinsen>
all you know is if a modifier is active *now*, which you can also see from it being on the enter list...
<kennylevinsen>
Maybe I'm missing something - just seems redundant at first glance
<kennylevinsen>
And I don't think my compositor would need libxkbcommon itself if it didn't have to track the modifiers
Fxzx_mic has quit [Ping timeout: 480 seconds]
<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
<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
<kchibisov>
ut.
<kchibisov>
But that's what I remember/know over the years in writing windowing stuff, so take it with the grain of salt.
<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'.
MrCooper_ is now known as MrCooper
<kennylevinsen>
Hmm I guess latching modifiers wouldn't be covered by checking held keys yeah
<kennylevinsen>
zamundaaa[m]: good point, forgot that MR
<kchibisov>
kennylevinsen: you also need an xkb in your compositor if you plan on having bindings.
<kchibisov>
Unless you have a proxy compositor ofc.
<kennylevinsen>
my compositor doesn't have bindings itself - currently offloaded to a manager client, maybe to a plugin instead soon
<kennylevinsen>
not that it's a huge issue that it has libxkbcommon, just felt silly to call out to *just* for modifier tracking
<kchibisov>
In general compositors have bindings and you have xkb_variant setting for weird layouts.
<kennylevinsen>
hmm I still need it for look up the keymap to read, so wouldn't be able to avoid it anyway
<kchibisov>
yeah, you need keymap + other settings reading.
<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.
<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
<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
<ifreund>
however, that growth along the y-axis extends beyond the height requested by the compositor
<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.
<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
<daniels>
kennylevinsen: not just latching but also locking modifiers
<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
<ifreund>
kennylevinsen: I set the resizing state during interactive resize, which is when mpv exhibits this behavior
<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
fmuellner has joined #wayland
kts has joined #wayland
<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
<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
<zamundaaa[m]>
no, it does not need to match the aspect ratio
<ifreund>
zamundaaa[m]: how would it be possible for resizing along only the x-axis to work?
<zamundaaa[m]>
ifreund: the window will simply stay the same size
<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
<ifreund>
the y axis has the exact same problem though
<zamundaaa[m]>
To be frank I don't understand where you see a problem?
<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
<ifreund>
zamundaaa[m]: the problem is that doing that as a user will be incredibly finnicky
<ifreund>
since the compositor is not aware of the aspect ration
<zamundaaa[m]>
The compositor does not need to make the size match any aspect ratio
<ifreund>
and resizing generally happens across many tiny incremental configures
<zamundaaa[m]>
The client is supposed to choose the biggest size that fits inside the configure bounds
<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
<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
Company has joined #wayland
<ifreund>
zamundaaa[m]: what firefox version? mine seems to paint black bars on the top and bottom of the video to maintain aspect ratio
<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
<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
<zamundaaa[m]>
no, it is not smaller configures. It is one absolute size limit
<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
<ifreund>
what compositor?
<zamundaaa[m]>
KWin
<ifreund>
and firefox is 100% not running through xwayland or something?
<ifreund>
just trying to figure out why the behavior is different for the same version
<zamundaaa[m]>
yes
mcf has joined #wayland
sangoma has quit [resistance.oftc.net reflection.oftc.net]
bluebugs has quit [resistance.oftc.net reflection.oftc.net]
coleman has quit [resistance.oftc.net reflection.oftc.net]
zzag has quit [resistance.oftc.net reflection.oftc.net]
eroc1990 has quit [resistance.oftc.net reflection.oftc.net]
kasper93 has quit [resistance.oftc.net reflection.oftc.net]
gspbirel5684008498790919236617 has quit [resistance.oftc.net reflection.oftc.net]
kelnos has quit [resistance.oftc.net reflection.oftc.net]
fullstop_ has quit [resistance.oftc.net reflection.oftc.net]
jsto has quit [resistance.oftc.net reflection.oftc.net]
danshick has quit [resistance.oftc.net reflection.oftc.net]
zvarde198830320677919168 has quit [resistance.oftc.net reflection.oftc.net]
ManMower has quit [resistance.oftc.net reflection.oftc.net]
Satan2 has quit [resistance.oftc.net reflection.oftc.net]
Sachiel has quit [resistance.oftc.net reflection.oftc.net]
zubzub has quit [resistance.oftc.net reflection.oftc.net]
cwittlut has quit [resistance.oftc.net reflection.oftc.net]
yar has quit [resistance.oftc.net reflection.oftc.net]
tlwoerner has quit [resistance.oftc.net reflection.oftc.net]
jlco has quit [resistance.oftc.net reflection.oftc.net]
overholts has quit [resistance.oftc.net reflection.oftc.net]
danieldg has quit [resistance.oftc.net reflection.oftc.net]
xyene has quit [resistance.oftc.net reflection.oftc.net]
dri-logger has quit [resistance.oftc.net reflection.oftc.net]
caseif has quit [resistance.oftc.net reflection.oftc.net]
aswar002 has quit [resistance.oftc.net reflection.oftc.net]
appusony__ has quit [resistance.oftc.net reflection.oftc.net]
quantum5 has quit [resistance.oftc.net reflection.oftc.net]
nurupo has quit [resistance.oftc.net reflection.oftc.net]
mcf has quit [resistance.oftc.net reflection.oftc.net]
BPCZd has quit [resistance.oftc.net reflection.oftc.net]
codingkoopa3 has quit [resistance.oftc.net reflection.oftc.net]
cnsvc has quit [resistance.oftc.net reflection.oftc.net]
riverdc_ has quit [resistance.oftc.net reflection.oftc.net]
ids1024 has quit [resistance.oftc.net reflection.oftc.net]
haasn has quit [resistance.oftc.net reflection.oftc.net]
bwidawsk has quit [resistance.oftc.net reflection.oftc.net]
melissawen has quit [resistance.oftc.net reflection.oftc.net]
sudocurse__ has quit [resistance.oftc.net reflection.oftc.net]
coleman has joined #wayland
melissawen has joined #wayland
nurupo has joined #wayland
caseif has joined #wayland
danshick has joined #wayland
riverdc has joined #wayland
zubzub has joined #wayland
fullstop has joined #wayland
appusony__ has joined #wayland
sudocurse__ has joined #wayland
cnsvc has joined #wayland
jlco has joined #wayland
Sachiel has joined #wayland
danieldg has joined #wayland
zzag has joined #wayland
zvarde198830320677919168 has joined #wayland
overholts has joined #wayland
jsto has joined #wayland
sangoma has joined #wayland
gspbirel5684008498790919236617 has joined #wayland
codingkoopa3 has joined #wayland
bwidawsk has joined #wayland
yar has joined #wayland
bluebugs has joined #wayland
haasn has joined #wayland
xyene has joined #wayland
tlwoerner has joined #wayland
kelnos has joined #wayland
quantum5 has joined #wayland
aswar002 has joined #wayland
kasper93 has joined #wayland
cwittlut has joined #wayland
ids1024 has joined #wayland
BPCZ has joined #wayland
Satan2 has joined #wayland
eroc1990 has joined #wayland
<ifreund>
I see the same behavior under weston and my compositor (river), not sure what kwin could be doing differently...
ManMower has joined #wayland
<zamundaaa[m]>
hmm, it does seem to be compositor dependent - I get black bars in Weston too. Maybe Firefox has a whitelist or sth
fmuellner has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
<zzag>
is the behavior different when XDG_SESSION_DESKTOP=KDE is set?
paulk-bis has quit [Ping timeout: 480 seconds]
caveman has quit [Quit: bbl]
<ifreund>
zzag: it does indeed, wtf
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
<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
___nick___ has joined #wayland
<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
<ifreund>
(testing under weston with XDG_SESSION_DESKTOP=KDE set
<ifreund>
also it has artifact (black bars) along the resize edges during the resize
caveman has joined #wayland
<ifreund>
I definitely wouldn't hold this up as an example of a client behaving perfectly
<zamundaaa[m]>
That's not the behavior I see, not even under Weston
<zamundaaa[m]>
Bugs like that are probably the reason why it's not doing that on Weston by default though
<ifreund>
oh, I might have a really old weston version
<ifreund>
9.0.0 isn't that old I guess
<zamundaaa[m]>
I'm on Weston 11.0.1
<ifreund>
zamundaaa[m]: I get the same behavior I saw on weston 9.0.0 on weston's current main branch
<ifreund>
black bars along the bottom and right edges during resize
<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)
<ifreund>
Can KWin be launched without logind these days?
<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