On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> Hi,
>
> On 31. 07. 20, 7:22, 张云海 wrote:
> > Remove whitespace at EOL
>
> I am fine with the patch. However it should be sent properly (inline
> mail, having a PATCH subject etc. -- see
> Documentation/process/submitting-patches.rst).
On 8/3/20 11:47 AM, Greg KH wrote:
> On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
>> On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
>>>
>>> On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
> Remove whitespace at
On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
> On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
> >
> > On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> > > Hi,
> > >
> > > On 31. 07. 20, 7:22, 张云海 wrote:
> > > > Remove whitespace at EOL
> > >
> > > I am fine with the
On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
>
> On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> > Hi,
> >
> > On 31. 07. 20, 7:22, 张云海 wrote:
> > > Remove whitespace at EOL
> >
> > I am fine with the patch. However it should be sent properly (inline
> > mail, having a PATCH
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> Hi,
>
> On 31. 07. 20, 7:22, 张云海 wrote:
> > Remove whitespace at EOL
>
> I am fine with the patch. However it should be sent properly (inline
> mail, having a PATCH subject etc. -- see
> Documentation/process/submitting-patches.rst).
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
> Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also
Remove whitespace at EOL
On 2020/7/30 18:39, 张云海 wrote:
> Update the patch, add CC list, sample output, and Jiri's PoC.
>
> On 2020/7/30 14:46, Jiri Slaby wrote:
>> Hi, OTOH, you should have CCed all the (public) lists.
>
>From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
Update the patch, add CC list, sample output, and Jiri's PoC.
On 2020/7/30 14:46, Jiri Slaby wrote:
> Hi, OTOH, you should have CCed all the (public) lists.
>From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
From: Yunhai Zhang
Date: Tue, 28 Jul 2020 09:58:03 +0800
Subject:
On 30. 07. 20, 8:46, Jiri Slaby wrote:
> Hi, OTOH, you should have CCed all the (public) lists.
>
> On 30. 07. 20, 4:50, 张云海 wrote:
>> Zhang Xiao points out that the check should use > instead of >=,
>> otherwise the last line will be skip.
>> I agree with that, so I modify the patch.
>> Could
Hi, OTOH, you should have CCed all the (public) lists.
On 30. 07. 20, 4:50, 张云海 wrote:
> Zhang Xiao points out that the check should use > instead of >=,
> otherwise the last line will be skip.
> I agree with that, so I modify the patch.
> Could you please verify that it is still correct and
Hi Jiri,
On 7/29/20 9:02 AM, Jiri Slaby wrote:
> The current vgacon's scroll up implementation uses a circural buffer
> in vgacon_scrollback_cur. It always advances tail to prepare it for the
> next write and caps it to zero if the next ->vc_size_row bytes won't fit.
>
> But when we change the
On 29. 07. 20, 10:19, 张云海 wrote:
> On 2020/7/29 16:11, Jiri Slaby wrote:
>> But the loop checks for the overflow:
>> if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
>> vgacon_scrollback_cur->tail = 0;
>>
>> So the first 2 iterations would write to the end of the buffer
On 2020/7/29 16:11, Jiri Slaby wrote:
> But the loop checks for the overflow:
> if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
> vgacon_scrollback_cur->tail = 0;
>
> So the first 2 iterations would write to the end of the buffer and this
> 3rd one should have zeroed
Hi,
On 29. 07. 20, 9:53, 张云海 wrote:
> This patch dosen't fix the issue, the check should be in the loop.
>
> The change of the VT sze is before vgacon_scrollback_update, not in the
> meantime.
>
> Let's consider the following situation:
> suppose:
>
Hi All,
This patch dosen't fix the issue, the check should be in the loop.
The change of the VT sze is before vgacon_scrollback_update, not in the
meantime.
Let's consider the following situation:
suppose:
vgacon_scrollback_cur->size is 65440
The current vgacon's scroll up implementation uses a circural buffer
in vgacon_scrollback_cur. It always advances tail to prepare it for the
next write and caps it to zero if the next ->vc_size_row bytes won't fit.
But when we change the VT size (e.g. by VT_RESIZE) in the meantime, the new
line
16 matches
Mail list logo
