From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Tom Li <tomli@tomli.me>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
LFBDEV <linux-fbdev@vger.kernel.org>,
dri-devel <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 21:59:36 +0100 [thread overview]
Message-ID: <CADVatmMt6Au2pGETZoKc3W9nz9ys9Up=KvsA8P0YzyUCyEDDww@mail.gmail.com> (raw)
In-Reply-To: <20190401164158.GC15736@localhost.localdomain>
On Mon, Apr 1, 2019 at 5:42 PM Tom Li <tomli@tomli.me> wrote:
>
> 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 think I will call that as a bug, a bug which did not export the
configuration and so it was not used. But, now that we know of the bug
we should fix the bug instead of removing the configuration.
>
> > 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.
Thanks.
--
Regards
Sudip
WARNING: multiple messages have this Message-ID (diff)
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Tom Li <tomli@tomli.me>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
LFBDEV <linux-fbdev@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes.
Date: Tue, 02 Apr 2019 20:59:36 +0000 [thread overview]
Message-ID: <CADVatmMt6Au2pGETZoKc3W9nz9ys9Up=KvsA8P0YzyUCyEDDww@mail.gmail.com> (raw)
In-Reply-To: <20190401164158.GC15736@localhost.localdomain>
On Mon, Apr 1, 2019 at 5:42 PM Tom Li <tomli@tomli.me> wrote:
>
> 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 think I will call that as a bug, a bug which did not export the
configuration and so it was not used. But, now that we know of the bug
we should fix the bug instead of removing the configuration.
>
> > 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.
Thanks.
--
Regards
Sudip
next prev parent reply other threads:[~2019-04-02 21:00 UTC|newest]
Thread overview: 60+ 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 ` 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-22 5:17 ` Yifeng Li
2019-03-31 17:16 ` Sudip Mukherjee
2019-03-31 17:16 ` Sudip Mukherjee
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-22 5:17 ` Yifeng Li
2019-03-31 17:25 ` Sudip Mukherjee
2019-03-31 17:25 ` Sudip Mukherjee
2019-04-01 16:04 ` Tom Li
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-22 5:17 ` Yifeng Li
2019-03-31 18:09 ` Sudip Mukherjee
2019-03-31 18:09 ` Sudip Mukherjee
2019-04-01 16:26 ` Tom Li
2019-04-01 16:26 ` Tom Li
2019-04-02 20:53 ` Sudip Mukherjee
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-22 5:17 ` Yifeng Li
2019-03-31 18:33 ` Sudip Mukherjee
2019-03-31 18:33 ` Sudip Mukherjee
2019-04-01 16:41 ` Tom Li
2019-04-01 16:41 ` Tom Li
2019-04-02 20:59 ` Sudip Mukherjee [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-22 5:17 ` Yifeng Li
2019-03-31 18:54 ` Sudip Mukherjee
2019-03-31 18:54 ` Sudip Mukherjee
2019-03-31 18:54 ` Sudip Mukherjee
2019-04-01 17:30 ` Tom Li
2019-04-01 17:30 ` Tom Li
2019-04-02 21:03 ` Sudip Mukherjee
2019-04-02 21:03 ` Sudip Mukherjee
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-22 5:17 ` Yifeng Li
2019-03-31 19:01 ` Sudip Mukherjee
2019-03-31 19:01 ` Sudip Mukherjee
2019-04-01 17:33 ` Tom Li
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-22 5:17 ` Yifeng Li
2019-03-31 19:08 ` Sudip Mukherjee
2019-03-31 19:08 ` Sudip Mukherjee
2019-03-31 19:08 ` Sudip Mukherjee
2019-04-01 17:41 ` Tom Li
2019-04-01 17:41 ` Tom Li
2019-04-02 21:09 ` Sudip Mukherjee
2019-04-02 21:09 ` Sudip Mukherjee
2019-04-02 21:09 ` Sudip Mukherjee
2019-04-03 13:53 ` Bartlomiej Zolnierkiewicz
2019-04-03 13:53 ` Bartlomiej Zolnierkiewicz
2019-04-05 22:11 ` Sudip Mukherjee
2019-04-05 22:11 ` Sudip Mukherjee
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='CADVatmMt6Au2pGETZoKc3W9nz9ys9Up=KvsA8P0YzyUCyEDDww@mail.gmail.com' \
--to=sudipm.mukherjee@gmail.com \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=teddy.wang@siliconmotion.com \
--cc=tomli@tomli.me \
/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.