On Tue, 4 Sep 2018, Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 7:04 PM, Mikulas Patocka mpatocka@redhat.com wrote:
On Tue, 4 Sep 2018, Daniel Vetter wrote:
On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie airlied@gmail.com wrote:
I've seen that you dropped this patch: https://patchwork.kernel.org/patch/10445393/
Is that patch correct or incorrect? In case it is incorrect, do you have an idea how should fbdefio be used properly on KMS drivers?
I suppose I was wondering what use fbdefio really has, modern code should be using KMS interface and the KMS dirty handling should be able to cover those cases.
I use fbdefio with the links 2 web browser and with fbi and fbgs image viewers.
I tried to look into modifying the links browser to work without fbdefio - but the DRM_IOCTL_MODE_DIRTYFB ioctl requires master mode, which means that it is unuseable by an unprivileged process. If you suggest how should console applications use the framebuffer without fbdefio, I can implement it.
Well with the console there's really no security. Either you disallow touching fbdev, or everyone can read&write whatever they want, even if they're not the currently active vt. So security just doesn't exist with fbdev.
I added myself to the video group, so that I can open /dev/fb0 and run graphics console applications. But I still can't set master mode, so I can't issue DRM_IOCTL_MODE_DIRTYFB to update the screen when fbdefio is turned off.
With kms you need logind or someone like that who orchestrates the vt switching and makes sure you can read/write other people's stuff.
The Links browser registers two signals via vt_mode.acqsig and vt_mode.relsig and repaints the screen or stops painting when they are received. If it should do something else - then what?
It would be nice if the kms developers provided a simple graphics console application that describes how to use it.
Mikulas