All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peilin Ye <yepeilin.cs@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c
Date: Tue, 17 Nov 2020 01:21:42 -0500	[thread overview]
Message-ID: <20201117062142.GA28766@PWN> (raw)
In-Reply-To: <20201116100949.GA401619@phenom.ffwll.local>

On Mon, Nov 16, 2020 at 11:09:49AM +0100, Daniel Vetter wrote:
> On Sat, Nov 14, 2020 at 07:47:16AM -0500, Peilin Ye wrote:
> > On Sat, Nov 14, 2020 at 01:22:22PM +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 14, 2020 at 01:18:06PM +0100, Greg Kroah-Hartman wrote:
> > > > On Sat, Nov 14, 2020 at 03:10:21AM -0500, Peilin Ye wrote:
> > > > > Thanks for reviewing!  Questions about the last patch [5/5] though, it
> > > > > depends on the following assumption:
> > > > > 
> > > > > """
> > > > > For each console `idx`, `vc_cons[idx].d->vc_font.data` and
> > > > > `fb_display[idx].fontdata` always point to the same buffer.
> > > > > """
> > > > > 
> > > > > Is this true?  I think it is true by grepping for `fontdata`.  I also
> > > > > noticed that fbcon.c is using `vc->vc_font.data` and `p->fontdata`
> > > > > interchangeably, see fbcon_get_requirement():
> > > > > 
> > > > > 		vc = vc_cons[fg_console].d;
> > > > > 		[...]
> > > > > 			p = &fb_display[fg_console];
> > > > > 			caps->x = 1 << (vc->vc_font.width - 1);
> > > > > 					^^^^^^^^^^^
> > > > > 			caps->y = 1 << (vc->vc_font.height - 1);
> > > > > 					^^^^^^^^^^^
> > > > > 			caps->len = (p->userfont) ?
> > > > > 				FNTCHARCNT(p->fontdata) : 256;
> > > > > 					   ^^^^^^^^^^^
> > > > > 
> > > > > If it is true, then what is the point of using `fontdata` in `struct
> > > > > fbcon_display`?  Just for the `userfont` flag?  Should we delete
> > > > > `fontdata`, when we no longer need the `userfont` flag?
> > > > 
> > > > Yes, after a quick look, I think your analysis here is correct.  So if
> > > > you can delete that, it would be nice if possible.
> > 
> > I see, at the moment we still need `userfont` for refcount handling, I
> > will try to delete both `fontdata` and `userfont` after refcount is
> > taken care of.
> 
> +1 on sunsetting fondata. I think there's a bunch of these in fbcon code,
> because the console subsystem is older than the standard "allow drivers to
> embed the subsystem struct into their own private struct" subclassing
> model. So lots of global arrays indexed by the console id :-/

Yeah, I saw your comments about registered_fb[] :(

> We're also trying to start some kind of test suite for fbdev chardev ioctl
> interface in the gpu test suite. fbcon tests are maybe more related to
> tty/vt, and I have no idea whether anything exists there already.
> 
> But if you want to do some automated testcases for fbcon and there's
> absolutely no other home for them, the gpu test suite might be an option
> of last resort too:
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation

Oh, I didn't know about igt-gpu-tools, thanks for the pointer!  Now,
since charcount is taken care of, and font_desc now contains all fields
of console_font, I think it is a good time to replace console_font with
font_desc in vc_data.  Then we can get rid of FNTSUM(), FNTSIZE(), then
(finally) REFCOUNT().

I will start working on vc_data, after done enough testing on [5/5],
ofc. Thanks,

Peilin Ye


WARNING: multiple messages have this Message-ID (diff)
From: Peilin Ye <yepeilin.cs@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jiri Slaby <jirislaby@kernel.org>
Subject: Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c
Date: Tue, 17 Nov 2020 01:21:42 -0500	[thread overview]
Message-ID: <20201117062142.GA28766@PWN> (raw)
In-Reply-To: <20201116100949.GA401619@phenom.ffwll.local>

On Mon, Nov 16, 2020 at 11:09:49AM +0100, Daniel Vetter wrote:
> On Sat, Nov 14, 2020 at 07:47:16AM -0500, Peilin Ye wrote:
> > On Sat, Nov 14, 2020 at 01:22:22PM +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 14, 2020 at 01:18:06PM +0100, Greg Kroah-Hartman wrote:
> > > > On Sat, Nov 14, 2020 at 03:10:21AM -0500, Peilin Ye wrote:
> > > > > Thanks for reviewing!  Questions about the last patch [5/5] though, it
> > > > > depends on the following assumption:
> > > > > 
> > > > > """
> > > > > For each console `idx`, `vc_cons[idx].d->vc_font.data` and
> > > > > `fb_display[idx].fontdata` always point to the same buffer.
> > > > > """
> > > > > 
> > > > > Is this true?  I think it is true by grepping for `fontdata`.  I also
> > > > > noticed that fbcon.c is using `vc->vc_font.data` and `p->fontdata`
> > > > > interchangeably, see fbcon_get_requirement():
> > > > > 
> > > > > 		vc = vc_cons[fg_console].d;
> > > > > 		[...]
> > > > > 			p = &fb_display[fg_console];
> > > > > 			caps->x = 1 << (vc->vc_font.width - 1);
> > > > > 					^^^^^^^^^^^
> > > > > 			caps->y = 1 << (vc->vc_font.height - 1);
> > > > > 					^^^^^^^^^^^
> > > > > 			caps->len = (p->userfont) ?
> > > > > 				FNTCHARCNT(p->fontdata) : 256;
> > > > > 					   ^^^^^^^^^^^
> > > > > 
> > > > > If it is true, then what is the point of using `fontdata` in `struct
> > > > > fbcon_display`?  Just for the `userfont` flag?  Should we delete
> > > > > `fontdata`, when we no longer need the `userfont` flag?
> > > > 
> > > > Yes, after a quick look, I think your analysis here is correct.  So if
> > > > you can delete that, it would be nice if possible.
> > 
> > I see, at the moment we still need `userfont` for refcount handling, I
> > will try to delete both `fontdata` and `userfont` after refcount is
> > taken care of.
> 
> +1 on sunsetting fondata. I think there's a bunch of these in fbcon code,
> because the console subsystem is older than the standard "allow drivers to
> embed the subsystem struct into their own private struct" subclassing
> model. So lots of global arrays indexed by the console id :-/

Yeah, I saw your comments about registered_fb[] :(

> We're also trying to start some kind of test suite for fbdev chardev ioctl
> interface in the gpu test suite. fbcon tests are maybe more related to
> tty/vt, and I have no idea whether anything exists there already.
> 
> But if you want to do some automated testcases for fbcon and there's
> absolutely no other home for them, the gpu test suite might be an option
> of last resort too:
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation

Oh, I didn't know about igt-gpu-tools, thanks for the pointer!  Now,
since charcount is taken care of, and font_desc now contains all fields
of console_font, I think it is a good time to replace console_font with
font_desc in vc_data.  Then we can get rid of FNTSUM(), FNTSIZE(), then
(finally) REFCOUNT().

I will start working on vc_data, after done enough testing on [5/5],
ofc. Thanks,

Peilin Ye

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-11-17  6:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 12:02 [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c Peilin Ye
2020-11-12 12:02 ` Peilin Ye
2020-11-12 12:04 ` [PATCH 1/5] console: Delete unused con_font_copy() callback implementations Peilin Ye
2020-11-12 12:04   ` Peilin Ye
2020-11-12 12:11 ` [PATCH v3 2/5] console: Delete dummy con_font_set() and con_font_default() " Peilin Ye
2020-11-12 12:11   ` Peilin Ye
2020-11-12 12:13 ` [PATCH v3 3/5] Fonts: Add charcount field to font_desc Peilin Ye
2020-11-12 12:13   ` Peilin Ye
2020-11-12 12:14 ` [PATCH v3 4/5] parisc/sticore: Avoid hard-coding built-in font charcount Peilin Ye
2020-11-12 12:14   ` Peilin Ye
2020-11-12 12:15 ` [PATCH v3 RFC 5/5] fbcon: Avoid using FNTCHARCNT() and hard-coded " Peilin Ye
2020-11-12 12:15   ` Peilin Ye
2020-11-13 21:16 ` [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c Daniel Vetter
2020-11-13 21:16   ` Daniel Vetter
2020-11-13 22:47   ` Greg Kroah-Hartman
2020-11-13 22:47     ` Greg Kroah-Hartman
2020-11-14  8:10     ` Peilin Ye
2020-11-14  8:10       ` Peilin Ye
2020-11-14 12:18       ` Greg Kroah-Hartman
2020-11-14 12:18         ` Greg Kroah-Hartman
2020-11-14 12:22         ` Greg Kroah-Hartman
2020-11-14 12:22           ` Greg Kroah-Hartman
2020-11-14 12:47           ` Peilin Ye
2020-11-14 12:47             ` Peilin Ye
2020-11-16 10:09             ` Daniel Vetter
2020-11-16 10:09               ` Daniel Vetter
2020-11-17  6:21               ` Peilin Ye [this message]
2020-11-17  6:21                 ` Peilin Ye
2020-11-19  8:32           ` Peilin Ye
2020-11-19  8:32             ` Peilin Ye
2020-11-19 15:10             ` Daniel Vetter
2020-11-19 15:10               ` Daniel Vetter
2020-11-20  8:37               ` Peilin Ye
2020-11-20  8:37                 ` Peilin Ye
2020-11-16 15:33     ` Daniel Vetter
2020-11-16 15:33       ` Daniel Vetter

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=20201117062142.GA28766@PWN \
    --to=yepeilin.cs@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.