On Thu, 10 Sep 2009, Daniel Mack wrote:

On Thu, Sep 10, 2009 at 08:35:51PM +0800, Eric Miao wrote:

quoted

On Thu, Sep 10, 2009 at 8:32 PM, Daniel Mack [off-list ref] wrote:

quoted

Hmm, I'd say you don't want fb.fix.accel set unless the driver is
enabled, right?

I'm not sure if it can be set anyway without the driver being
built.

DirectFB userspace applications take that value to decide whether to
enable the acceleration driver or go for software fallbacks. If that
field is set, the kernel is expected to come along with the driver
interface.

Hence, it should really only be set if the driver is enabled, otherwise
the userspace logic breaks.

quoted

I mean - I don't want Kconfig option to cross modules.

I agree, and it would be even better to only set that field in case the
driver has actually been probed (and not just enabled in the kernel
config). But I see no clean way to do that - the gcu driver has no
access to the framebuffer driver and its data structs either.

Yeah, that doesn't look pretty. Maybe add a field to struct 
pxafb_mach_info? You can put its assignment in respective platform data 
instances under an #ifdef - that's more acceptable, IMHO. Of course, it is 
still worse than beeing able to switch this at run-time. But you could 
trick by setting that field at run-time if acceleration is available, 
provided you have that info before pxafb initialises. Also consider, there 
might be more PXA SoCs in the future using pxafb and providing hardware 
acceleration.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/