From: Tom Li <tomli@tomli.me>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>,
linux-kernel@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes.
Date: Tue, 2 Apr 2019 00:41:58 +0800 [thread overview]
Message-ID: <20190401164158.GC15736@localhost.localdomain> (raw)
In-Reply-To: <20190331183333.kpyt2hm5iy6m5u34@debian>
On Sun, Mar 31, 2019 at 07:33:33PM +0100, Sudip Mukherjee wrote:
> Why are you removing existing functionality from the driver? These are
> supported but were never listed so could not be used. I think you can
> just add these to vesa_mode_table[] and they can be used.
If there are some "functionalities" in a system, but they are never used,
even worse, they are programmed in a way that they cannot be used by any
user no matter what, meanwhile not a single user had filed a bug report
in the entire lifecycle of the program, then I'd call them "dead code",
that serves no useful purposes, rather than "functionalities". I think
most kernel developers can agree on this.
> I have an old CRT in India which supports 320x240 mode and can test there
> when I am there next.
Well... If someone (e.g. you) do see a need of this feature, then fixing
them (instead of removing them) becomes a reasonable choice.
Coincidentally, I've also purchased a video converter a few days ago. Please
allow some time for me to testing it, so I can see if they're working. If so,
I'll add them to the vesa_mode_table[] in PATCH v3.
> > /**********************************************************************
> > SM712 Mode table.
> > - **********************************************************************/
> > +
> > + The modesetting in sm712fb is an ugly hack. First, all the registers
> > + are programmed by hardcoded register arrays, which makes it difficult
> > + to support different variations of color depths, refresh rates, CRT/LCD
> > + panel, etc of the same resolution. Second, it means the standard
> > + fb_find_mode() cannot be used and a confusing non-standard "vga="
> > + parameter is needed. Third, there's only minimum differences between
> > + some modes, yet around 70 lines of code and 100 registers are needed to
> > + be indepentently specified for each mode. Fourth, the register between
> > + some modes are inconsistent: the register configuration of different
> > + color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> > + it's completely different. Also, some modes can drive the LCD panel
> > + properly yet some other modes will only show a white screen of death on
> > + the LCD panel. Fifth, there is a specific hack for Lemote Loongson 8089D
> > + laptop, the 1024x768, 16-bit color mode was modified to drive its LCD panel
> > + and changed to 1024x600, but the original mode was not preserved, so
> > + 1024x768 16-bit color mode is completely unsupported. And previously,
> > + some modes are listed, such as 1280x1024 modes, but never supported by
> > + the register configuration arrays, so they are now removed. And some modes
> > + are partially implemented but neither listed nor supported, i.e. the 8-bit
> > + color modes, so they have been removed from vesa_mode_table, too.
>
> I think this comment sounds more like a commit message instead of a
> code comment. Does this improve readability?
Will remove, thanks.
>
> > +
> > + I'm not the original author of the code, fixing these problems requires a
> > + complete rewrite of modesetting code, which is well-beyond my motivation.
> > +
> > + See Documentation/fb/sm712fb.txt for more information.
> > +**********************************************************************/
>
> Is this needed? Many of the commits of the driver are done by people who
> are not the original author.
I'll reword it.
Thanks,
Tom Li
next prev parent reply other threads:[~2019-04-01 16:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 5:17 [PATCH v2 0/7] implement 2D acceleration, minor cleanups, doc updates Yifeng Li
2019-03-22 5:17 ` [PATCH v2 1/7] fbdev: sm712fb: use type "u8" for 8-bit I/O Yifeng Li
2019-03-31 17:16 ` Sudip Mukherjee
2019-03-22 5:17 ` [PATCH v2 2/7] fbdev: sm712fb: add 2D-related I/O headers and functions Yifeng Li
2019-03-31 17:25 ` Sudip Mukherjee
2019-04-01 16:04 ` Tom Li
2019-03-22 5:17 ` [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU Yifeng Li
2019-03-31 18:09 ` Sudip Mukherjee
2019-04-01 16:26 ` Tom Li
2019-04-02 20:53 ` Sudip Mukherjee
2019-03-22 5:17 ` [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes Yifeng Li
2019-03-31 18:33 ` Sudip Mukherjee
2019-04-01 16:41 ` Tom Li [this message]
2019-04-02 20:59 ` Sudip Mukherjee
2019-03-22 5:17 ` [PATCH v2 5/7] Documentation: fb: sm712fb: add information mainly about 2D Yifeng Li
2019-03-31 18:54 ` Sudip Mukherjee
2019-04-01 17:30 ` Tom Li
2019-04-02 21:03 ` Sudip Mukherjee
2019-03-22 5:17 ` [PATCH v2 6/7] fbdev: sm712fb: Kconfig: add information about docs Yifeng Li
2019-03-31 19:01 ` Sudip Mukherjee
2019-04-01 17:33 ` Tom Li
2019-03-22 5:17 ` [PATCH v2 7/7] MAINTAINERS: sm712fb: list myself as one maintainer Yifeng Li
2019-03-31 19:08 ` Sudip Mukherjee
2019-04-01 17:41 ` Tom Li
2019-04-02 21:09 ` Sudip Mukherjee
2019-04-03 13:53 ` Bartlomiej Zolnierkiewicz
2019-04-05 22:11 ` Sudip Mukherjee
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=20190401164158.GC15736@localhost.localdomain \
--to=tomli@tomli.me \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=teddy.wang@siliconmotion.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).