On Fri, 2019-06-14 at 14:34 +0200, Marco Felsch wrote: > On 19-06-14 13:11, [email protected] wrote: > > On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote: > > > Anyway thats > > > interessting. IMHO it isn't a good solution to rely on that fact > > > that > > > the package have some 'random' default enabled drivers. Should we > > > fix > > > the qemu configs or should I add: > > > > > > PACKAGECONFIG_append_qemuall = " swrast" > > > > The assumption is that swrast makes a good fallback and would be > > available in most cases. > > No I don't think that it is a good fallback, following my patch > description. If you are on a embedded device you want the hw-renderer > and not the sw one. A good example: After I updated my kernel, my > hw-renderer wasn't available anymore and my application didn't start. > Thats a very good indication that something went bad. With the swrast > enabled I wouldn't see that immediately.
Alternatively, if swrast is available the system is more usable and you can then have a more usable system to track down the problem and fix it? My point is you can argue that both ways. I did read your commit message. > > I suspect qemuall might not fix beaglebone-yocto or some of the > > hardware BSPs. > > As I discribed in the patch description if you want that fallback you > have to enable it. IMHO this is the better way instead of to be a > 'smart' package. As things stand this patch will likely break a significant number of BSPs. This isn't acceptable. > > Its also assumed these packages are shared amongst multiple > > machines > > which may need different drivers. > > > > I suspect this means the defaults should be on but I am happy to > > have > > more PACKAGECONFIG options to control things for people who want to > > customise/micro-optimise. > > Optimising wasn't my main motivation. Avoiding 'random' performace > issues after a upgrade (kernel, mesa) was my main motivation. Do you > get me? I understand why you're doing it however I don't like the implications of the change which mean breakage for a significant number of BSPs, and the fact it breaks the way distros would use this recipe from a packaging perspective as its not marked as machine specific, nor should it be. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
