I mean runqemu does already have

def check_render_nodes(self):

where this should be fixed. Sorry can't help myself :)

Alex

On Wed, 23 Aug 2023 at 20:40, Alexander Kanavin via
lists.openembedded.org <[email protected]>
wrote:
>
> Better yet, how about fixing this at the source, i.e. qemu itself?
> Sorry for the rapid-fire :)
>
> Alex
>
> On Wed, 23 Aug 2023 at 20:38, Alexander Kanavin <[email protected]> 
> wrote:
> >
> > Oh, and device should be /dev/dri/render*, and all of this should be in 
> > runqemu.
> >
> > Alex
> >
> > On Wed, 23 Aug 2023 at 20:37, Alexander Kanavin <[email protected]> 
> > wrote:
> > >
> > > On Wed, 23 Aug 2023 at 08:10, Mikko Rapeli <[email protected]> 
> > > wrote:
> > > >
> > > > If access to /dev/dri/renderD128 fails, then qemu with 3d graphics will
> > > > fail to start and errors are rather cryptic like:
> > > >
> > > > qemu-system-x86_64: egl: render node init failed
> > > >
> > > > To fix this, users likely need to
> > > >
> > > >  * modprobe vgem
> > > >  * add their user to "render" group to write to /dev/dri/renderD128
> > > >
> > > > If access is not available due to missing HW, driver or failing access,
> > > > then skip the test:
> > >
> > > This should be a failure rather than a skip. Otherwise, autobuilder
> > > testing will silently regress and no one will notice. The error
> > > message should include information from IOError as well so that it's
> > > clear that the issue is device file permissions.
> > >
> > > Alex
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186630): 
https://lists.openembedded.org/g/openembedded-core/message/186630
Mute This Topic: https://lists.openembedded.org/mt/100910043/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to