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:51 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: linkBe 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.