[git pull] drm udl fixes

[Daniel Vetter]

On Tue, Sep 4, 2018 at 7:04 PM, Mikulas Patocka <mpatocka at redhat.com> wrote:
>
>
> On Tue, 4 Sep 2018, Daniel Vetter wrote:
>
>> On Tue, Sep 4, 2018 at 1:41 AM, Dave Airlie <airlied at 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.

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.

>> > I don't really like the maintainability decrease moving to in-driver
>> > page handling causes vs using shmem.
>>
>> I think tinydrm has the same problem of shmem+fbdefio, could be worth
>> it to chat with Noralf. Adding him.
>
> Perhaps we could allocate tiny structures that point to pages and
> construct the list from them - but it would require rewriting all the
> fbdefio drivers, and I wonder if anyone has all the hardware that uses
> fbdefio to test it.

We could just entirely implement our own defio copy in drm_fb_helpers.
Not sure that's worth it against the coast of yet another cpu copy.
Anyone still stuck using fbcon will expect performance from the 90s,
and you can do lots of cpu copies and still be fast enough :-)

I'd recommend you use the generic defio stuff Noralf has created and
see how that goes. Best case it's a good cleanup for drm/udl by
switching over to the gem helpers and generic fbdev code.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch