On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:

Hi Ajay,

On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:

quoted

Hi Baruch,
On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach [off-list ref] wrote:

quoted

Hi Ajay,

On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:

quoted

This patch adds a data structure definiton to hold framebuffer windows/planes.
An ioctl number is also added to provide user access
to change window position dynamically.

[snip]

quoted

+/* Window overlaying */
+struct fb_overlay_win_pos {
+     __u32 win_pos_x;        /* x-offset from LCD(0,0) where window starts */
+     __u32 win_pos_y;        /* y-offset from LCD(0,0) where window starts */
+};

Why not allow negative offsets where the left or upper part of the framebuffer
is hidden?

Thanks for pointing it out. Are there drivers which place the overlay
windows such that some part of the window is hidden from being
displayed on the screen?

I don't know. However, since this is new userspace ABI which should stay 
compatible forever, we should make sure to do it right. Using __s32 instead of 
__u32 won't limit us in the future.

OMAP HW doesn't allow "funny" things like overlay being outside the
visible area, i.e. negative position or size larger than the display.
And my guess is that hardware rarely allow things like that, as it would
just complicate the hardware without any gain.

Out-of-display-overlays can of course be emulated by the software. But
I'm not sure if it's good to add the complexity in the driver layer, as
it could as well be handled in the userspace.

Then again, a signed value would be future safer ("just in case"), and
if the driver can just reject values it doesn't want to support, there's
no real harm there either.

 Tomi