Daaanct12 has quit [Remote host closed the connection]
<bumpkinbye[m]>
<uvos> "1. 8 bit key codes, you cant..." <- So wayland is not an improvement for the n900
<bumpkinbye[m]>
Vsync is great on xorg for me and a nonissue
_whitelogger has joined #maemo-leste
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
xmn has quit [Ping timeout: 276 seconds]
macros_ has quit [Ping timeout: 246 seconds]
macros_ has joined #maemo-leste
joerg has quit [Ping timeout: 276 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
ceene has quit [Ping timeout: 272 seconds]
mardy has joined #maemo-leste
Twig has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
ceene has joined #maemo-leste
pere has joined #maemo-leste
alex1216 has joined #maemo-leste
dev has joined #maemo-leste
branon has quit [Remote host closed the connection]
branon has joined #maemo-leste
uvos has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
<uvos>
wayland is an especially massive advantage on very low end systems like n900
<uvos>
disregarding defficancies in the x11 client protocoll, having the compositor and the display server in one process saves a lot of ram, and processor time vs shuffeling things around via ipc
<uvos>
now uncomposited xorg can be on par with this with wayland
<uvos>
but uncomposited xorg is not whats used on n900
macros_ has quit [Ping timeout: 255 seconds]
macros_ has joined #maemo-leste
uvos has quit [Remote host closed the connection]
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
macros_ has quit [Quit: Closed IRC Client]
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
macros_ has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: I don't see how WL can be any faster than h-d, unless *all* rendering is done on GPU, which I don't think is possible ATM
<freemangordon>
leste has fps drop when h-d is running because of the compositing h-d does, not because xorg
<freemangordon>
i.e, h-d uses TFP/offscreen buffer, but that means that all the application rendering shall be done before h-d start dealing with that texture
<freemangordon>
kinda glReadPixels()
<freemangordon>
so, there might be some performance penalty because of xorg protocol, but it is negligible compared to waiting for all application offscreen buffer GPU rendering to complete before bliting to the front buffer
<freemangordon>
not to say that this WL thing smells to me like gdi32.dll, those who know WINAPI will understand
<buZz>
i think my SD card of yesterday just broke, making a fresh install from new image tarball now, copying my /home/user over
<buZz>
should be enough, right? :P
<buZz>
maybe /etc to /home/user/oldetc just in case ;)
uvos has joined #maemo-leste
pere has joined #maemo-leste
<uvos>
freemangordon: its not about presenting
<uvos>
freemangordon: h-d has to sync its clutter geometry with the postitions of xwindows via ipc with x
<uvos>
this takes extra cycles than if the the clients just told h-d directly about window state
<uvos>
instead of it going client -> xorg -> hd -> xorg -> client for every event
<uvos>
also if an application dose any rendering via x this is slower too than the application just doing it in its own process context
<uvos>
rendering via x here bing using core x draw calls or xrender
<freemangordon>
agree
<freemangordon>
but I don;t think this has *that* big performance impact
<uvos>
and sure the diff in composed x vs wayland is less than the diff between uncomposed x and composed x
<uvos>
but i wasent talking about that
<freemangordon>
uvos: for sure there is overhead and deficiencies in x protocol
<uvos>
i was specificly talking about the speed difference between composited x and wayland, wich as you say, rendering is mostly the same
<freemangordon>
but I don;t think that is a sane reason to throw the baby with the water, and this is what upstream is doing
<uvos>
but x has extra ipc penalty
<uvos>
in comperasin plain old x is quite sane imo
<uvos>
sure as i said they should have just depricated the draw calls and such and called that x12
<freemangordon>
also, I am regularly using git gui running on d4 and my PS runs Xephyr as display server for that git gui
<uvos>
way less pain for most of the beneifit
<freemangordon>
*PC
<freemangordon>
I don;t think anything like that is possible with WL
<freemangordon>
could be wrong though, I am not familiar with WL protocol
<uvos>
what remoting?
<freemangordon>
mhm
<uvos>
or nested display servers?
<freemangordon>
both
<uvos>
both are possible with wayland
<freemangordon>
it it?
<uvos>
yeah
<freemangordon>
ok
<uvos>
its less "nice"
<uvos>
since it needs display server support
<uvos>
and there are manny wayland display servers
<uvos>
while on x it just works universally
<freemangordon>
yeah
<freemangordon>
ok, /me is back to work
<uvos>
on wl you really need to spin up a speical display server for the windows you want to push to antoher machine
<freemangordon>
sounds more like a hack
<uvos>
eh i mean not really
<uvos>
not more than just pusing bitmaps over x11 is
<uvos>
which is what happens with modern apps in the remote case
<uvos>
but yeah not ideal either
<buZz>
hehe, feels this new 2022-10-23 image boots faster than my old install :P
<buZz>
but i also moved from my old 16GB sd to a new-ish 64GB
<buZz>
hmmmm .. 'ok' keys dont work on the new image by default?
<buZz>
i thought we made those the default ages ago, (i tried 'ok' plus ',' to get ';')
<uvos>
udevadm hwdb --update
<uvos>
udevadm trigger
<uvos>
it may not work on first boot
<uvos>
btw
<buZz>
its the third or fourth boot
<buZz>
but, didnt enable -devel yet, just did, updating now
<uvos>
well did updating the hwdb help?
<buZz>
whats the package for 'making calls' again?
<uvos>
sphone?
<buZz>
some meta pkg?
<uvos>
there is
<uvos>
idk name tho
<buZz>
udevadm hwdb --update; trigger doesnt do anything
<buZz>
i mean, doesnt fix the keyb
<uvos>
hildon-conectivity-mobile
<uvos>
or so
<buZz>
oh right
<buZz>
ty
<buZz>
o hey, we already have pocophone-f1 targets in package tree? TIL
<buZz>
hmm, -mobile was already installed, weird
<buZz>
welp, got agenda back, contacts back and sync back, guess this is fine for now :P
uvos has quit [Ping timeout: 272 seconds]
<buZz>
oh, guess i wont have wireguard yet, thats probably not stored in /home/user ?
<buZz>
you know, i'd like a nicer default theme :P one that doesnt have black-on-black in calendar and some other views :P
<buZz>
anyone know the meta package to get xmpp working? :P the presence stuff i guess?
<buZz>
at least gprs data works first try :P
<buZz>
uvos: btw, rebooting after apt update did get me functional 'ok' keyboard keys
<buZz>
well, enabling -devel and updating and rebooting
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
nedko has joined #maemo-leste
ceene has quit [Remote host closed the connection]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
xmn has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
ikmaak has quit [Ping timeout: 260 seconds]
ikmaak has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
jr-logbot` has quit [Remote host closed the connection]