Hi Theo,
thank you for your reply. Well then, I guess I just stop switching
around between different login sessions ;)
Nils
Am 31.07.2020 um 16:08 schrieb Theo de Raadt:
> I'm not sure what can be done about it.
>
> /etc/fbtab's first role is to give access to subsystems, but it's
> second more important role is to *take them away* later.
>
> Unfortunately there is nothing "keeping state" about previous access
> conditions, as well it is quite unclear if reverting to previous access
> conditions would be a safe choice.
>
>
> =?UTF-8?Q?Nils_Reu=c3=9fe?= <n.reusse@hxgn.net> wrote:
>
>> Dear all,
>>
>> logging in and out changes the owner of the /dev/drm0 file, so that one
>> loses hardware acceleration in X when additionally logging in and out on
>> a console. Here's what I do:
>>
>> 1) Boot Openbsd and log into X with xenodm. Ownership of /dev/drm0:
>>
>> $ ls -l /dev/drm0
>> crw------- 1 nils wheel 87, 0 Jul 31 13:07 /dev/drm0
>>
>> 2) Switch to a console (e.g. CTRL-ALT-F1) and log in with the same user.
>> The file is now owned by my user-group:
>>
>> $ ls -l /dev/drm0
>> crw------- 1 nils nils 87, 0 Jul 31 13:07 /dev/drm0
>>
>> 3) Log out from the console. Ownership changes back to root/wheel,
>> thereby disabling hardware acceleration in X:
>>
>> $ ls -l /dev/drm0
>> crw------- 1 root wheel 87, 0 Jul 31 13:07 /dev/drm0
>>
>> To regain hardware acceleration, I have to manually chown the file back
>> to my userid, or relogin with xenodm. So I guess logging in chowns the
>> file with my user (even with my user group when logging in via console),
>> and logging out reassigns the file owner to root.
>>
>> I guess not much can be done about this, or can it?
>>
>> Nils
>>
No comments:
Post a Comment