ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Company has quit [Quit: Leaving]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
danieldg has quit [Ping timeout: 480 seconds]
catman has quit [Quit: WeeChat 3.6]
vanveldt has joined #wayland
wolfshappen has quit [Ping timeout: 480 seconds]
danieldg has joined #wayland
wolfshappen has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
Dami-star has quit []
Dami_Lu has joined #wayland
colordrops has quit [Ping timeout: 480 seconds]
vanveldt has quit []
remyabel2 has quit [Remote host closed the connection]
nerdopolis_ has quit [Ping timeout: 480 seconds]
remyabel2 has joined #wayland
dcz_ has joined #wayland
squeezy has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
cvmn has joined #wayland
squeezy has quit []
squeezy has joined #wayland
squeezy_ has joined #wayland
squeezy_ has quit []
squeezy has quit []
remyabel2 has quit [Remote host closed the connection]
remyabel2 has joined #wayland
remyabel2 has quit []
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
remyabel2 has joined #wayland
markbolhuis has joined #wayland
markbolhuis has quit []
danvet has joined #wayland
remyabel2 has quit [Remote host closed the connection]
remyabel2 has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
markbolhuis has joined #wayland
remyabel2 has quit [Quit: remyabel2]
jgrulich has quit [Remote host closed the connection]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
sozuba has joined #wayland
vanveldt has joined #wayland
sozuba has quit []
Company has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
wolfshappen has quit [Ping timeout: 480 seconds]
devilhorns has joined #wayland
wolfshappen has joined #wayland
van_veldt has joined #wayland
vanveldt has quit [Remote host closed the connection]
markbolhuis1 has joined #wayland
markbolhuis1 has quit []
markbolhuis has quit [Ping timeout: 480 seconds]
<pq>
Weston does not expose support for DRM_FORMAT_ARGB8888 nor DRM_FORMAT_XRGB8888... only the WL_SHM_FORMAT_* aliases are listed.
<pq>
maybe I should fix that
<daniels>
pq: expose through which interface ... ?
<pq>
wl_shm
<pq>
looks like that can be fixed by deleting code
<davidre>
The best kind of fix
<bl4ckb0ne>
ship it
<pq>
hmm, but these DRM_FORMAT codes are not listed in wayland.xml.
<pq>
I could add a pixel_format_get_wl_shm_format() that special-cases these two and otherwise returns DRM fourcc, but ugh.
<daniels>
the last time I touched that, I tried to just always convert to/from those two special format codes at the SHM boundary, and leave everything else as FourCC
<pq>
yeah, but my problem is that I wanted to use pixel-formats.c database in the test suite, because I need to convert to/from Pixman codes.
devilhorns has quit []
<pq>
when create_shm_buffer() looks up the pixel format from the db, it needs something to pass as the wl_shm format
<pq>
so I think pixel_format_get_shm_format() actually fits, and I don't have to tweak the renderers
bodiccea_ has joined #wayland
<emersion>
pq, what i've done is conversion functions between DRM_FORMAT_* and WL_SHM_FORMAT_* with the two special cases
<emersion>
and then i used DRM_FORMAT_* everywhere
sozuba has joined #wayland
<pq>
that's what I decided to do now, was just lacking a DRM -> wl_shm converter
bodiccea has quit [Ping timeout: 480 seconds]
sozuba has quit []
<daniels>
emersion: yeah
sozuba has joined #wayland
sozuba has quit [Quit: sozuba]
nerdopolis has joined #wayland
<bl4ckb0ne>
i should really make that format convertion header
<pq>
will it be endian-portable? :>
markbolhuis has joined #wayland
markbolhuis has quit [Remote host closed the connection]
markbolhuis has joined #wayland
<bl4ckb0ne>
maybe
jgrulich has joined #wayland
<pq>
What's WL_SHM_FORMAT_ARGB8888 on big-endian? ;-)
<pq>
I seriously don't know.
<emersion>
that's an easy one
<daniels>
yeah: unused
<emersion>
unused?
<daniels>
well, maybe someone's using wl_shm on a G5, but I'm not sure who that person would be
<emersion>
ah, you mean BE is unused altogether
<daniels>
yeah ... Arm and MIPS let you choose which endianness you want, but I'm not aware of anyone having done either as big-endian in about a decade?
<pq>
emersion, the two original wl_shm formats were made to match the Cairo formats. DRM formats have little-endian definition, Cairo formats are machine-endian just like Pixman... but which definition works on BE after all the arbitrary byteswaps people do? :-p
<emersion>
ah, so there was a trap
<emersion>
i didn't know WL_SHM_FORMAT_* was designed after Cairo initially
<daniels>
'if a tree falls in a forest ...'
<pq>
I don't think they were designed... they just matched Cairo to make it work nicely
<emersion>
daniels, i've received wlrotos patches to make addfb2 work on BE…
<daniels>
emersion: :o
<pq>
then DRM formats came along and everyone forgot the definitions are not quite the same
<daniels>
still though, good news that you found a big-endian maintainer to fix all the problems :)
<emersion>
pq, yeah, i just assumed everything matched DRM
<pq>
emersion, one possible interpretation would be that WL_SHM_FORMAT_ARGB888 has a machine-endian definition, while DRM_FORMAT_ARGB8888 has little-endian definition. On LE they are aliases, on BE not.
<emersion>
that's pretty sad
<pq>
but I would bet that everyone thought they are always aliases
<emersion>
"same as DRM" is much more simple
<pq>
...which also means that Wayland Cairo apps on BE are probably broken
<MrCooper>
daniels: s390x is still BE :) not sure anyone's running Wayland clients on that though
<pq>
I also have a feeling that one of these formats on BE machine are not really supported by GL
mbalmer has joined #wayland
<pq>
or maybe that was just DRM_FORMAT_RGB565 on BE
<daniels>
MrCooper: you should ask IBM!
<MrCooper>
pretty much anything should be supported by GL in theory, though the set of apps which would get that right on BE in practice might be empty
<pq>
sorry, in GL ES
<MrCooper>
daniels: I could ask somebody at RH
<bl4ckb0ne>
i rember s390x having no graphics
<MrCooper>
no HW acceleration, just llvmpipe
<bl4ckb0ne>
ah yes
<emersion>
wlroots doesn't run on llvmpipe anymore sadly
<emersion>
llvmpipe + FBO = sad
<MrCooper>
I know there are RHEL users using that, every now and then our team needs to fix bugs with that setup
<daniels>
emersion: ??
<daniels>
emersion: FBOs definitely work ... or right, I guess you mean doing dmabuf -> EGLImage -> FBO
<emersion>
daniels, we don't use EGLSurface in wlroots
<daniels>
yeah
<emersion>
and there's no way to import a shm into llvmpipe as FBOP
<emersion>
FBO*
<pq>
you tried vgem too?
<emersion>
vulkan does support it via VK_EXT_external_memory_host
<emersion>
pq, hm, but i'd want to not relay vgem DMA-BUFs to KMS/Wayland/X11
<pq>
where, what... umm?
<pq>
where does the shm originate that you need to draw into via FBO?
<emersion>
when you use llvmpipe with EGLSurface, it uses e.g. wl_shm instead of linux-dmabuf
<emersion>
if i use llvmpipe FBOs with vgem DMA-BUFs, maybe that _could_ work, but it's still like to use wl_shm or DRM dumb buffers or MIT-SHM in the backend
<emersion>
i'd still*
<pq>
it's like you are talking about all the imaginable paths at the same time
<emersion>
okay, let's say i want to use llvmpipe with the DRM backend
<pq>
for KMS, you'd create a dumb buffer, export dmabuf, import via EGL to FBO, render with llvmpipe; does that not work?
<emersion>
hm. maybe that works, but it's "by chance", because DRM dumb buffers can be DMA-BUF'ed
<pq>
I wouldn't call that "by chance"
<emersion>
if i want to run with the Wayland backend instead
<emersion>
then it doesn't work anymore
<pq>
correct, unless vgem
<emersion>
vgem wouldn't help
<pq>
why?
<emersion>
so you allocate a GBM buffer via vgem, import + render via llvmpipe right?
<pq>
I would expect that theoretically to work, yeah
<emersion>
but then how do you use wl_shm to pass that buffer to the parent compositor?
<pq>
you use dmabuf protocol, not wl_shm
<emersion>
llvmpipe is used on systems without a GPU
<emersion>
the parent compositor is unlikely to have linux-dmabuf
<bl4ckb0ne>
why
<pq>
right, so you can't have a dmabuf to begin with
<emersion>
what i'd want is an EGL ext to create an EGLImage from an arbitrary chunk of memory
<pq>
(the parent compositor could expose dmabuf interface, but they likely won't bother)
<emersion>
enabled in llvmpipe only
<emersion>
that way i can tell llvmpipe to render to this chunk of memory, just like i'd use pixman