From: Peilin Ye <yepeilin.cs@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Following up
Date: Tue, 27 Oct 2020 12:50:21 -0400 [thread overview]
Message-ID: <20201027165021.GA1178130@PWN> (raw)
In-Reply-To: <cover.1603788511.git.yepeilin.cs@gmail.com>
Hi Daniel,
More about the 3 things we've discussed before:
1. Cleaning up con_font_op():
(drivers/tty/vt/vt.c)
int con_font_op(struct vc_data *vc, struct console_font_op *op)
{
switch (op->op) {
case KD_FONT_OP_SET:
return con_font_set(vc, op);
case KD_FONT_OP_GET:
return con_font_get(vc, op);
case KD_FONT_OP_SET_DEFAULT:
return con_font_default(vc, op);
case KD_FONT_OP_COPY:
return con_font_copy(vc, op);
}
return -ENOSYS;
}
On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> I think if we change the conf_font_get/set/default/copy functions to not
> take the *op struct (which is take pretty arbitrarily from one of the
> ioctl), but the parameters each needs directly, that would clean up the
> code a _lot_.
This is on my TODO list! One day I came up with some idea about
fbcon.c, so I postponed this a bit...
2. Removing dummy functions, like sisusbdummycon_font_set():
Turns out, before c396a5bf457f ("console: Expand dummy functions for
CFI"), they were just some macros:
-#define SISUSBCONDUMMY (void *)sisusbdummycon_dummy
+static int sisusbdummycon_font_set(struct vc_data *vc,
+ struct console_font *font,
+ unsigned int flags)
+{
+ return 0;
+}
...and they had been there for a very long (10+ years) time. Removing
code like this makes me a bit nervous, and...
On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> This actually does something. tbh I would not be surprises if the
> fb_set utility is the only thing that uses this - with a bit of code
> search we could perhaps confirm this, and delete all the other
> implementations.
...you mentioned code search, where & what should we look at, in order
to confirm it's safe to remove them?
3. Using `font_desc` in `vc_data`:
Our plan for the gradual conversion was to use a helper function to
set font for a vc, but after reviewing the 300-ish occurrence of
`vc_font`, it seems like code doesn't usually set it as a whole:
(drivers/usb/misc/sisusbvga/sisusb_con.c)
[...]
c->vc_font.height = sisusb->current_font_height;
[...]
...that's it! It only cares about the height. There are only 4 or 5
places in fbcon.c that actually set all fields of `vc_font`, like:
vc->vc_font.width = font->width;
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
vc->vc_font.charcount = 256; /* FIXME Need to support more fonts */
To make it even more complicated, `p` is a `struct fbcon_display *`,
containing yet another font data pointer (`fontdata`) that I think
should be replaced by a `font_desc *`...
In conclusion, I think it's all about a few hard problems in fbcon.c.
I'll keep trying and see how it goes.
Thank you,
Peilin Ye
WARNING: multiple messages have this Message-ID (diff)
From: Peilin Ye <yepeilin.cs@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Following up
Date: Tue, 27 Oct 2020 12:50:21 -0400 [thread overview]
Message-ID: <20201027165021.GA1178130@PWN> (raw)
In-Reply-To: <cover.1603788511.git.yepeilin.cs@gmail.com>
Hi Daniel,
More about the 3 things we've discussed before:
1. Cleaning up con_font_op():
(drivers/tty/vt/vt.c)
int con_font_op(struct vc_data *vc, struct console_font_op *op)
{
switch (op->op) {
case KD_FONT_OP_SET:
return con_font_set(vc, op);
case KD_FONT_OP_GET:
return con_font_get(vc, op);
case KD_FONT_OP_SET_DEFAULT:
return con_font_default(vc, op);
case KD_FONT_OP_COPY:
return con_font_copy(vc, op);
}
return -ENOSYS;
}
On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> I think if we change the conf_font_get/set/default/copy functions to not
> take the *op struct (which is take pretty arbitrarily from one of the
> ioctl), but the parameters each needs directly, that would clean up the
> code a _lot_.
This is on my TODO list! One day I came up with some idea about
fbcon.c, so I postponed this a bit...
2. Removing dummy functions, like sisusbdummycon_font_set():
Turns out, before c396a5bf457f ("console: Expand dummy functions for
CFI"), they were just some macros:
-#define SISUSBCONDUMMY (void *)sisusbdummycon_dummy
+static int sisusbdummycon_font_set(struct vc_data *vc,
+ struct console_font *font,
+ unsigned int flags)
+{
+ return 0;
+}
...and they had been there for a very long (10+ years) time. Removing
code like this makes me a bit nervous, and...
On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> This actually does something. tbh I would not be surprises if the
> fb_set utility is the only thing that uses this - with a bit of code
> search we could perhaps confirm this, and delete all the other
> implementations.
...you mentioned code search, where & what should we look at, in order
to confirm it's safe to remove them?
3. Using `font_desc` in `vc_data`:
Our plan for the gradual conversion was to use a helper function to
set font for a vc, but after reviewing the 300-ish occurrence of
`vc_font`, it seems like code doesn't usually set it as a whole:
(drivers/usb/misc/sisusbvga/sisusb_con.c)
[...]
c->vc_font.height = sisusb->current_font_height;
[...]
...that's it! It only cares about the height. There are only 4 or 5
places in fbcon.c that actually set all fields of `vc_font`, like:
vc->vc_font.width = font->width;
vc->vc_font.height = font->height;
vc->vc_font.data = (void *)(p->fontdata = font->data);
vc->vc_font.charcount = 256; /* FIXME Need to support more fonts */
To make it even more complicated, `p` is a `struct fbcon_display *`,
containing yet another font data pointer (`fontdata`) that I think
should be replaced by a `font_desc *`...
In conclusion, I think it's all about a few hard problems in fbcon.c.
I'll keep trying and see how it goes.
Thank you,
Peilin Ye
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-10-27 16:50 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 16:27 [PATCH 0/5] Preparation work for using font_desc in vc_data Peilin Ye
2020-10-27 16:27 ` Peilin Ye
2020-10-27 16:31 ` [PATCH 1/5] fbdev/atafb: Remove unused extern variables Peilin Ye
2020-10-27 16:31 ` Peilin Ye
2020-10-27 16:33 ` [PATCH 2/5] Fonts: Make font size unsigned in font_desc Peilin Ye
2020-10-27 16:33 ` Peilin Ye
2020-10-27 16:34 ` [PATCH 3/5] Fonts: Add charcount field to font_desc Peilin Ye
2020-10-27 16:34 ` Peilin Ye
2020-10-27 16:37 ` [PATCH 4/5] fbcon: Avoid hard-coding built-in font charcount Peilin Ye
2020-10-27 16:37 ` Peilin Ye
2020-10-27 16:41 ` [PATCH 5/5] parisc/sticore: " Peilin Ye
2020-10-27 16:41 ` Peilin Ye
2020-10-27 19:18 ` Daniel Vetter
2020-10-27 19:18 ` Daniel Vetter
2020-10-27 19:13 ` [PATCH 4/5] fbcon: " Daniel Vetter
2020-10-27 19:13 ` Daniel Vetter
2020-10-28 5:30 ` Peilin Ye
2020-10-28 5:30 ` Peilin Ye
2020-10-28 15:51 ` [PATCH RFC v2 4/5] fbdev: Avoid using FNTCHARCNT() and hard-coded " Peilin Ye
2020-10-28 15:51 ` Peilin Ye
2020-10-27 18:59 ` [PATCH 3/5] Fonts: Add charcount field to font_desc Daniel Vetter
2020-10-27 18:59 ` Daniel Vetter
2020-10-28 6:11 ` Peilin Ye
2020-10-28 6:11 ` Peilin Ye
2020-10-28 6:05 ` [PATCH 3/5 v2] " Peilin Ye
2020-10-28 6:05 ` Peilin Ye
2020-11-02 15:03 ` Daniel Vetter
2020-11-02 15:03 ` Daniel Vetter
2020-10-27 18:50 ` [PATCH 2/5] Fonts: Make font size unsigned in font_desc Daniel Vetter
2020-10-27 18:50 ` Daniel Vetter
2020-10-28 5:43 ` Peilin Ye
2020-10-28 5:43 ` Peilin Ye
2020-10-28 8:18 ` Daniel Vetter
2020-10-28 8:18 ` Daniel Vetter
2020-10-28 10:30 ` Peilin Ye
2020-10-28 10:30 ` Peilin Ye
2020-10-28 10:56 ` [PATCH v2 " Peilin Ye
2020-10-28 10:56 ` Peilin Ye
2020-10-28 18:40 ` Daniel Vetter
2020-10-28 18:40 ` Daniel Vetter
2020-10-27 18:44 ` [PATCH 1/5] fbdev/atafb: Remove unused extern variables Daniel Vetter
2020-10-27 18:44 ` Daniel Vetter
2020-10-28 9:59 ` Geert Uytterhoeven
2020-10-28 9:59 ` Geert Uytterhoeven
2020-10-28 19:25 ` Thomas Zimmermann
2020-10-28 19:25 ` Thomas Zimmermann
2020-10-27 16:50 ` Peilin Ye [this message]
2020-10-27 16:50 ` Following up Peilin Ye
2020-10-27 18:36 ` Daniel Vetter
2020-10-27 18:36 ` Daniel Vetter
2020-10-28 5:34 ` Peilin Ye
2020-10-28 5:34 ` Peilin Ye
2020-11-02 15:01 ` [PATCH 0/5] Preparation work for using font_desc in vc_data Daniel Vetter
2020-11-02 15:01 ` 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=20201027165021.GA1178130@PWN \
--to=yepeilin.cs@gmail.com \
--cc=b.zolnierkie@samsung.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.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.