Message-ID: <4E74EF98.3060106@gmx.de>
Date:	Sat, 17 Sep 2011 19:06:00 +0000
From:	Florian Tobias Schandinat <FlorianSchandinat@....de>
To:	Dave Airlie <airlied@...il.com>
CC:	Rob Clark <rob@...com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, Archit Taneja <archit@...com>,
	linux-fbdev@...r.kernel.org
Subject: Re: Proposal for a low-level Linux display framework

On 09/17/2011 06:23 PM, Dave Airlie wrote:
>>
>> Is it? Well, okay, I don't want to use any acceleration that can crash my
>> machine, where can I select it, preferably as compile time option? I didn't find
>> such a thing for Intel or Radeon. Don't say, I should rely on userspace here or
>> use fbdev for this.
> 
> Just tell the X driver to not use acceleration, and it you won't get
> any acceleration used, then you get complete stability. If a driver
> writer wants to turn off all accel in the kernel driver, it can, its
> not an option we've bothered with for intel or radeon since it really
> makes no sense. To put it simply you don't really seem to understand
> the driver model around KMS. If no userspace app uses acceleration
> then no acceleration features will magically happen. If you want to
> write a simple app against the KMS API like plymouth you can now use
> the dumb ioctls to create and map a buffer that can be made into a
> framebuffer. Also you get hw cursors + modesetting.

Again, you seem to not understand my reasoning. The "if" is the problem, it's
the kernels job to ensure stability. Allowing the userspace to decide whether it
crashes my machine is not acceptable to me.
I do not claim that it is impossible to write a KMS driver in a way that it does
not crash, but it seems more difficult than writing an fbdev driver.

>> The thing is that the core fbdev API does not expose any acceleration to
>> userspace, maybe some drivers do via IOCTLs, but I hope that are only things
>> that can be done in a sane way, otherwise I'd consider it a bug. The story is
>> different for DRM/KMS, as I understand, as this was primarily for acceleration
>> and only recently got modesetting capabilities.
> 
> The core drm/kms ioctls don't expose acceleration to userspace either,
> again misinformation seems to drive most of your logic. You can't do
> generic useful acceleration from the kernel. A lot of modern GPU
> hardware doesn't even have bitblt engines.

I did not say that it is used directly for acceleration, but wasn't the point of
DRM to allow acceleration in the first place?

>> It's true that mmap can be PITA, but I don't see any real alternative given that
>> you want directly map video memory, especially on low end systems. And there are
>> ways around it, you can forbid mapping (though probably most userspace wouldn't
>> like it, I guess) or use any other solution like defio.
>> If you'd stop exposing the fbdev userspace interface it'd just harden my opinion
>> that KMS is a piece of trash and that I should avoid hardware that does not have
>> a native framebuffer driver. I think you shouldn't do this, as it's just a
>> disadvantage for your end users, but I personally do not really care.
> 
> We've fixed this in KMS, we don't pass direct mappings to userspace
> that we can't tear down and refault. We only provide objects via
> handles. The only place its a problem is where we expose fbdev legacy
> emulation, since we have to fix the pages.

I guess we could do the same in fbdev. It's probably just that nobody is
interested in it as we do not really care about memory management.


Best regards,

Florian Tobias Schandinat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists