I guess the patch needs a small tweak so that swrast remains enabled, but becomes optional. Then Marco can set packageconfig exactly as he wants.
The second patch is fine as it is, I think. Only qemu implements virgl device at the moment. Alex > On 14 Jun 2019, at 14.50, [email protected] wrote: > >> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
