On Thu, Feb 25, 2021 at 09:14:06PM +0000, Stuart Henderson wrote: > On 2021/02/25 22:02, Marcus Glocker wrote: > > On Thu, Feb 25, 2021 at 08:00:32PM +0000, Stuart Henderson wrote: > > > > > On 2021/02/25 20:10, Marcus Glocker wrote: > > > > We had this discussion recently when fbtab(5) for xenodm(1) was fixed > > > > 6 weeks ago, but we didn't come to an agreement yet. tb@ asked me the > > > > same question yesterday whether we can add video(1) to fbtab to avoid > > > > manual chown of /dev/video0, which I think a lot of people do today. > > > > Therefore here another try to bring this up. > > > > > > I'm not sure this is something I would expect to be chmod'ed > > > automatically.. It's a very different class of device than things > > > currently in fbtab or Give/TakeConsole. > > > > > > At least if this is done we'll have to document it somewhere for people > > > using ports like multimedia/motion. > > > > Um - I don't know this port, but glancing over it, it's a daemon running > > under the _motion user which is accessing /dev/video*? So people > > using that today are chowning /dev/video* to _motion? > > chown or chgrp - yes.
I see. I wouldn't know what is the right place to document that the video device would be owned by the console or xenodm login user. What would you suggest, in the impacted port itself or centrally, like in the video(4) man page? > > > > This diff adds /dev/video0 to fbtab on all archs where video is > > > > available. It's added for the existing console login entry, in case > > > > people start X through startx/xinit, and on a new entry when X is > > > > started through xenodm. > > > > > > Hmm - last time I suggested fbtab for something jcs pointed out > > > that it doesn't work with xenodm.. > > > > Did you read my first sentence? :-) > > Oh... :)
