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
avnt has quit [Quit: leaving]
EmetSelch has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
hergertme has quit [Remote host closed the connection]
<tleydxdy>
it seems like when weston is nested in another wayland compositor it is not passing in the relative pointer information to the clients? using the x11-backend it does pass in the relevant info
<pym_>
I encounter some compilation trouble with Weston 10.0.0 related to GLESv3 header files inclusion
Company has joined #wayland
<pym_>
My GPU chip doesn't support (yet) GLESv3 and this leads some trouble in my side.
<pq>
pym_, ah, yeah, we didn't account for missing that header. All you need to do is to get the header from somewhere, you should be good runtime anyway.
<pq>
I believe many distributions compile software against Mesa or Khronos headers, regardless of which actual drivers will be used eventually. The API is standard.
<pym_>
Well given the change I agree this is just Pixel format IDs
<pym_>
But I had similar issue with KMSCUBE where real GLESv3 runtime dependencies exist
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
what GLESv3 runtime dependencies?
<pym_>
This is GLESv3 features like texturator at Shader level
<pym_>
I don't recall other things though
<pq>
aha, right
<pym_>
We had to really get rid of them
<pq>
Weston is trying hard to remain GL ES 2 compatible, as long as you don't need color management or HDR.
<pq>
or those few pixel formats
<pym_>
Moreover we are willing to avoid misunderstanding by not exposing GLESv3 header files whereas GPU doesn't support it
<pym_>
Our GPU doesn't expose GLESv3 Header as not supporting it
<ManMower>
as pq mentioned those headers are Standard API.
<ManMower>
the headers are GPU agnostic
<pq>
pym_, your GPU is not even supposed to. The headers come from Khronos, e.g. with libglvnd.
<ManMower>
the software will detect what the GPU can do at runtime and not use the stuff from the headers that the GPU doesn't support
<ManMower>
but you really do need new headers to build software that targets multiple EGL versions
<pym_>
I know this is really "pixel format" ID from GLESv2 Ext to GLESv3 but what will happen if real GLESv3 Feature
<pq>
pym_, are thinking that apps would be calling GLESv3 functions directly? Nope, only broken apps would try that. Proper apps use eglGetProcAddress() *after* checking the GL version or the extension strings that the feature is indeed there.
<ManMower>
if we're actually using a glesv3 feature when we shouldn't that would be a bug, but I hope we're not, and it has nothing to do with which headers are installed on the system.
* ManMower
has noticed that he's conflating EGL and GLES, and decides to wander back into the woodpile before he muddies the water any more. ;)
<ManMower>
but yeah, it's not related to header presence, this is all checked at runtime
<pym_>
Doest it mean KMSCUBE is badly written ?
wv has quit []
<ManMower>
not meaning to be rude, but this isn't the KMSCUBE support channel ;)
wvanhauwaert has joined #wayland
<pym_>
of course
<ManMower>
you may find someone here that knows that code well, but it's not the best place to ask
<pq>
it might be taking unwarranted shortcuts, I haven't looked
<pym_>
Agree just wanted to get your feedback
<pym_>
ok ok
<pq>
Weston definitely shouldn't, we care about that
<ManMower>
I don't want to say anything bad about code I don't know well, because I don't want to make a mistake and offend someone.
<pym_>
So I guess in the future you will necessary check prior to call GLESv3 call
<pym_>
however I don't see why you used pixel format from GLESv3 and not GLESv2 Ext.
<pym_>
Since wwe don't have GLESv3 header we had to redefine pixel formats (i.e. #define GL_RGBA16F 0x881A = GL_RGBA16F_EXT)
zebrag has joined #wayland
slattann has quit [Quit: Leaving.]
jagan_ has joined #wayland
<ManMower>
is that define really the only thing we require from GLESv3 headers to build?
<pq>
it's not, at least if you enable color-lcms module.
<pq>
I'm not sure we check for RGBA16F extension... if we only check for GLESv3, then using GLESv3 names is natural.
<ManMower>
agreed completely, and was just typing something similar.
<ManMower>
fishing through various spec docs is hard enough as it is, using "the wrong" defines doesn't help...
<pq>
with some things, the extension and the GLESv3 thing are not quite the same either, and in that supporting both is a real pain - I've removed something like that in the past
ahartmetz has quit [Quit: Konversation terminated!]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
<pq>
734c2278f93cf39d7564f28f2be0719deeaadb22 was what I was recalling
<jagan_>
Hi, i'm running weston onf 5.10 imx kernel with LVDS panel enabled. I can see the Panel working. but weston is unable to start
<jagan_>
[17:44:50.718] DRM: head 'LVDS-1' found, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
<jagan_>
[17:44:50.718] Registered plugin API 'weston_drm_output_api_v1' of size 24
<jagan_>
[17:44:50.718] format 0x34325241 not supported by output LVDS-1
<jagan_>
[17:44:50.719] Failed to init output gl state
<jagan_>
any inputs?
ppascher has joined #wayland
<pq>
pym_, again, you simply get *all* GL, GL ES, and EGL headers from Khronos, and build things with those, instead of using the GPU vendor headers.
<pq>
jagan_, I'm not familiar with the platform, but like ManMower says, the error is saying that KMS cannot do argb pixel format. I guess both xrgb and argb fail, since it should try both as they are "compatible".
<pq>
jagan_, what kind of panel is it, does not do 8 bit per channel?
<jagan_>
yes support 8 bpc and it being used in upstream as well.
<ManMower>
datasheet for TM070JDHG30 claims 8bpc support
<pq>
hm
<pq>
I have a feeling this was a typical thing for something, but I don't remember at all.
<pq>
the trigger for the error message is when the kernel does not advertise support for the given pixel format in KMS
<jagan_>
I have hdmi on the same design adv7533 finding the similar issue
<jagan_>
[17:20:07.672] DRM: head 'HDMI-A-1' found, connector 35 is connected, EDID make 'RTK', model 'RTK FHD HDR ', serial 'demoset-1'
<jagan_>
[17:20:07.673] Registered plugin API 'weston_drm_output_api_v1' of size 24
<jagan_>
[17:20:07.674] format 0x34325241 not supported by output HDMI-A-1
<pq>
why is it argb...
<pq>
jagan_, does /etc/xdg/weston/weston.ini perhaps say something about gbm-format?
<pq>
I'm not actually that surprised that KMS might not advertise ARGB8888, and Weston should be defaulting to XRGB8888, so why is it trying argb...
<LaserEyess>
emersion: not to add to the bikeshedding, but are you looking for feedback for libdisplay-info from media people? both from the power user side of people who actually edit their own EDIDs and from e.g. mpv devs who use certain EDID parameters?
<emersion>
LaserEyess: oh yeah for sure
<emersion>
if you could summarize mpv's needs for instance, that would be helpful
<emersion>
and other feedback welcome ofc
<LaserEyess>
I couldn't for sure, but haasn for instance or even JEEB
<LaserEyess>
but I hang out with a bunch of people who are obsessed with this sort of thing, I could show it to them and see what they think
<emersion>
yeah, maybe ask them if it would be useful for mpv in the first place
<emersion>
i don't see any EDID bits in mpv
<LaserEyess>
I don't think it does either, but for color management stuff and ICC profiles it is important to know exactly what can be provided
eroc1990 has joined #wayland
<haasn>
I'm not familiar enough with the context to be of much use
<haasn>
What I'd want to know about a display is the HDR metadata stuff
<haasn>
But that should be a fairly obvious translation of what's available in EDID