On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote: > On 12/19/2017 05:02 PM, Daniel Vetter wrote: > > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt <mstaudt@xxxxxxx> wrote: > >> On 12/19/2017 02:57 PM, Daniel Vetter wrote: > >>> The problem is that defio is totally not how a real driver works. > >> > >> But they do exist and I can't ignore them. > >> > >> I'm afraid I don't understand - why are those, such as xenfb, not real drivers? > > > > I mean kms drivers. The problem is that the magic mapping that fbdev > > expects is real pain. Everyone else, including kms, expects an > > explicit flush operation. So instead of hacking around even more with > > the defio corner cases that don't work, I'm suggesting we just add > > that flush operation. At least internally. > > > > Fixing kms drivers to implement a better defio is probably not a > > reasonable investement of time. > > Ah yes, I understand now, you mean that KMS drivers have explicit flush, > and defio is a hack to retrofit such drivers to an API that never > supported a flush operation (the fbdev API), but always used to expose > the video memory directly. Right? > > If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even > solve my problem - I'd still need to implement flush. So might as well > care about the flush straight away, yep! Yup. I'll leave the more fundamental discussion to the other thread on the cover letter. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
