All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liu Ying <liu.y.victor@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Liu Ying <Ying.Liu@freescale.com>,
	g.liakhovetski@gmx.de, linux-fbdev@vger.kernel.org,
	FlorianSchandinat@gmx.de, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
Date: Mon, 11 Jun 2012 19:18:00 +0800	[thread overview]
Message-ID: <CA+8Hj83+Jqv3Bs0mTKYpdsH4ZbOMEQkRpsiCUPVwpeqvWg8jyA@mail.gmail.com> (raw)
In-Reply-To: <20120611110517.GE11168@n2100.arm.linux.org.uk>

2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
>> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> >> This patch checks if framebuffer is unblanked before
>> >> we actually trigger panning in custom pan display
>> >> function.
>> >>
>> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> >> ---
>> >>  drivers/video/mx3fb.c |    5 +++++
>> >>  1 files changed, 5 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> >> index e3406ab..d53db60 100644
>> >> --- a/drivers/video/mx3fb.c
>> >> +++ b/drivers/video/mx3fb.c
>> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> >> fb_var_screeninfo *var,
>> >>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> >>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>> >>
>> >> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> >> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> >> +		return -EFAULT;
>> >> +	}
>> >
>> > Why is this an error, and why return -EFAULT?  What userspace access
>> > failed?
>> >
>> Hi, Russell,
>>
>> IMHO, panning with framebuffer blanked is meaningless, at least, it is
>> not a common usecase.
>
> Yes, but why should anything in userspace care whether the display is
> blanked or not?
>
> For example, we may pan the display when a user program produces output,
> and we're on the last line of the display.  We don't fail that just
> because the screen happens to be blank.  So I don't see why we should
> actively fail an explicit userspace pan request just because the console
> happened to be blanked.
>
> What I'm basically saying is that as far as _userspace_ is concerned,
> all the standard APIs should just work as normal whether the display is
> blanked or not.
>

Ok, understand your point. I am ok to drop this patch.

Thanks.

-- 
Best Regards,
Liu Ying

WARNING: multiple messages have this Message-ID (diff)
From: Liu Ying <liu.y.victor@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
Date: Mon, 11 Jun 2012 11:18:00 +0000	[thread overview]
Message-ID: <CA+8Hj83+Jqv3Bs0mTKYpdsH4ZbOMEQkRpsiCUPVwpeqvWg8jyA@mail.gmail.com> (raw)
In-Reply-To: <20120611110517.GE11168@n2100.arm.linux.org.uk>

2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
>> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> >> This patch checks if framebuffer is unblanked before
>> >> we actually trigger panning in custom pan display
>> >> function.
>> >>
>> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> >> ---
>> >>  drivers/video/mx3fb.c |    5 +++++
>> >>  1 files changed, 5 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> >> index e3406ab..d53db60 100644
>> >> --- a/drivers/video/mx3fb.c
>> >> +++ b/drivers/video/mx3fb.c
>> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> >> fb_var_screeninfo *var,
>> >>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> >>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>> >>
>> >> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> >> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> >> +		return -EFAULT;
>> >> +	}
>> >
>> > Why is this an error, and why return -EFAULT?  What userspace access
>> > failed?
>> >
>> Hi, Russell,
>>
>> IMHO, panning with framebuffer blanked is meaningless, at least, it is
>> not a common usecase.
>
> Yes, but why should anything in userspace care whether the display is
> blanked or not?
>
> For example, we may pan the display when a user program produces output,
> and we're on the last line of the display.  We don't fail that just
> because the screen happens to be blank.  So I don't see why we should
> actively fail an explicit userspace pan request just because the console
> happened to be blanked.
>
> What I'm basically saying is that as far as _userspace_ is concerned,
> all the standard APIs should just work as normal whether the display is
> blanked or not.
>

Ok, understand your point. I am ok to drop this patch.

Thanks.

-- 
Best Regards,
Liu Ying

WARNING: multiple messages have this Message-ID (diff)
From: liu.y.victor@gmail.com (Liu Ying)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] mx3fb: do not support panning with fb blanked
Date: Mon, 11 Jun 2012 19:18:00 +0800	[thread overview]
Message-ID: <CA+8Hj83+Jqv3Bs0mTKYpdsH4ZbOMEQkRpsiCUPVwpeqvWg8jyA@mail.gmail.com> (raw)
In-Reply-To: <20120611110517.GE11168@n2100.arm.linux.org.uk>

2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
>> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> >> This patch checks if framebuffer is unblanked before
>> >> we actually trigger panning in custom pan display
>> >> function.
>> >>
>> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> >> ---
>> >>  drivers/video/mx3fb.c |    5 +++++
>> >>  1 files changed, 5 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> >> index e3406ab..d53db60 100644
>> >> --- a/drivers/video/mx3fb.c
>> >> +++ b/drivers/video/mx3fb.c
>> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> >> fb_var_screeninfo *var,
>> >>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> >>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>> >>
>> >> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> >> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> >> +		return -EFAULT;
>> >> +	}
>> >
>> > Why is this an error, and why return -EFAULT?  What userspace access
>> > failed?
>> >
>> Hi, Russell,
>>
>> IMHO, panning with framebuffer blanked is meaningless, at least, it is
>> not a common usecase.
>
> Yes, but why should anything in userspace care whether the display is
> blanked or not?
>
> For example, we may pan the display when a user program produces output,
> and we're on the last line of the display.  We don't fail that just
> because the screen happens to be blank.  So I don't see why we should
> actively fail an explicit userspace pan request just because the console
> happened to be blanked.
>
> What I'm basically saying is that as far as _userspace_ is concerned,
> all the standard APIs should just work as normal whether the display is
> blanked or not.
>

Ok, understand your point. I am ok to drop this patch.

Thanks.

-- 
Best Regards,
Liu Ying

  reply	other threads:[~2012-06-11 11:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11  1:06 [PATCH 1/3] mx3fb: do not support panning with fb blanked Liu Ying
2012-06-11  1:06 ` Liu Ying
2012-06-11  1:06 ` Liu Ying
2012-06-11  1:06 ` [PATCH 2/3] mx3fb: support pan display with fb_set_var Liu Ying
2012-06-11  1:06   ` Liu Ying
2012-06-11  1:06   ` Liu Ying
2012-07-02  6:28   ` Florian Tobias Schandinat
2012-07-02  6:28     ` Florian Tobias Schandinat
2012-07-02  6:28     ` Florian Tobias Schandinat
2012-06-11  1:06 ` [PATCH 3/3] mx3fb: avoid screen flash when panning " Liu Ying
2012-06-11  1:06   ` Liu Ying
2012-06-11  1:06   ` Liu Ying
2012-07-02  2:18   ` Liu Ying
2012-07-02  2:18     ` Liu Ying
2012-07-02  2:18     ` Liu Ying
2012-06-11  9:51 ` [PATCH 1/3] mx3fb: do not support panning with fb blanked Russell King - ARM Linux
2012-06-11  9:51   ` Russell King - ARM Linux
2012-06-11  9:51   ` Russell King - ARM Linux
2012-06-11 10:46   ` Liu Ying
2012-06-11 10:46     ` Liu Ying
2012-06-11 10:46     ` Liu Ying
2012-06-11 11:05     ` Russell King - ARM Linux
2012-06-11 11:05       ` Russell King - ARM Linux
2012-06-11 11:05       ` Russell King - ARM Linux
2012-06-11 11:18       ` Liu Ying [this message]
2012-06-11 11:18         ` Liu Ying
2012-06-11 11:18         ` Liu Ying

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=CA+8Hj83+Jqv3Bs0mTKYpdsH4ZbOMEQkRpsiCUPVwpeqvWg8jyA@mail.gmail.com \
    --to=liu.y.victor@gmail.com \
    --cc=FlorianSchandinat@gmx.de \
    --cc=Ying.Liu@freescale.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.