From: Kai Jiang <b18973@freescale.com>
To: "Ville Syrjälä" <syrjala@sci.fi>
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [linux-fbdev-devel][PATCH]fb_pan_display:add x/yoffset check
Date: Mon, 06 Jul 2009 10:54:11 +0800 [thread overview]
Message-ID: <4A516753.30506@freescale.com> (raw)
In-Reply-To: <20090703153029.GK9980@sci.fi>
We can't suppose that all the user operating this x/yoffset will check
it. If the user application transfer a negative x/yoffset into the fb
driver, I suppose fb driver should do operation correctly. So here, I
think checking x/yoffset to insure the virtual space not moving outside
real screen is necessary.
> On Tue, Jun 30, 2009 at 11:25:52AM +0800, Kai Jiang wrote:
>
>> xres,yres,xres_virtual,yres_virtual will be set in the display driver, they have actual value which match the screen(will not very huge).
>>
>> And here, these lines are not checking the overflowing, but checking whether the virtual space display is beyond the real screen.
>>
>> Take x boundary for example:(the screen x and virtual x relationship should be:)
>> xres+xoffset<xres_vritual && xoffset>0
>> This insure that, in the real screen, there are virtual picture display in the screen. When we move the virtual picture to the left, the xoffset will be smaller and smaller
>> to indicate the virtual picture is moving to the left. Finally, the xoffset will be zero when the screen left boundary and virtual picture left boundary overlap. When virtual display is still moving to the left, the xoffset will be negative. And what should be displayed in the gap between screen left boundary and virtual space left boundary?
>>
>
> If you're storing negative values into xoffset/yoffset your application
> is buggy. Just fix it.
>
>
>> So here we have to check the whether the x/yoffset is smaller than zero. If the offset is smaller than zero, in the driver, we should not move the virtual screen any more.
>>
>
> Checking for overflow will catch you buggy application's negative
> values too.
>
>
------------------------------------------------------------------------------
prev parent reply other threads:[~2009-07-06 2:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 3:49 [linux-fbdev-devel][PATCH]fb_pan_display:add x/yoffset check Kai Jiang
2009-06-29 10:39 ` Ville Syrjälä
2009-06-30 3:25 ` Kai Jiang
2009-07-03 15:30 ` Ville Syrjälä
2009-07-03 16:11 ` Florian Tobias Schandinat
2009-07-06 3:00 ` Kai Jiang
2009-07-06 14:12 ` Florian Tobias Schandinat
2009-07-07 2:43 ` Kai Jiang
2009-07-07 4:01 ` Florian Tobias Schandinat
2009-07-10 8:22 ` Kai Jiang
2009-08-03 18:58 ` [PATCH] fb: fix fb_pan_display range check Florian Tobias Schandinat
2009-07-06 2:54 ` Kai Jiang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A516753.30506@freescale.com \
--to=b18973@freescale.com \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=syrjala@sci.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).