Skip to content
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.

Development

Noralf Trønnes edited this page Feb 26, 2022 · 35 revisions

FBTFT is a dead end

The fbdev maintainer won't accept any new fbdev drivers: No more new fbdev drivers, please, so fbtft can't be moved out of staging. Greg Kroah-Hartman has stated that he will keep fbtft in staging until a matching DRM driver is present in the tree. Patches are still accepted.


The FBTFT drivers are now in the Linux kernel: drivers/staging/fbtft.
Development in this github repo has ceased and moved to the staging tree.

MAINTAINERS entry:

FBTFT Framebuffer drivers
L:	[email protected]
L:	[email protected]
S:	Orphan
F:	drivers/staging/fbtft/

Select the recipients for your patch:

$ ./scripts/get_maintainer.pl --file drivers/staging/fbtft/
Greg Kroah-Hartman <[email protected]> (supporter:STAGING SUBSYSTEM)
[email protected] (open list:FBTFT Framebuffer drivers)
[email protected] (open list:FBTFT Framebuffer drivers)
[email protected] (open list:STAGING SUBSYSTEM)
<...>

Resources:

The path from the staging tree to Linus' tree:

> So if I get this right, this is the tree I'll be basing my work on:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> So what's with the various staging-* branches?

I have 4 branches in that git tree:
	master - copy of Linus's tree, used to make patches against.
	staging-linus - patches to send to Linus for this -rc series
	staging-next - patches to send to Linus for the next -rc series
	staging-testing - patches that are being "tested" at the moment,
	and will move to staging-next if they pass.

These 28 patches went into staging-testing, and if everything looks ok,
in a day or so will move automatically into staging-next.  When the next
kernel is released by Linus (3.19), I will then have him pull from my
staging-next branch during the merge window period (merge windows are
for subsystem maintainers, not normal developers).

Then, after the big merge window is over, I will take bugfixes that need
to get into this kernel release into staging-linus, and stuff for the
next release (new drivers, changes not fixing regressions, etc.) into
the staging-next branch.

staging-next and staging-linus are pulled into the linux-next tree every
day (see Documenatation/development_model/ for more details about all of
this.)

So do your work against staging-testing, and all should be fine.

Submitting patches

I you want me to include your driver, follow these rules:

  • The license the code is released under has to be GPL version 2 or later. Add this information at the top of the file.

  • Agree with the Developer's Certificate of Origin 1.1 (12. Sign your work)

  • Follow the Linux kernel coding style
    Use linux/scripts/checkpatch.pl --file fb_xxx.c to verify your code.
    Lines can exceed 80 columns if the meaning is hard to grasp when breaking up the line. Never exceed 132 columns.

  • Make an issue and include your driver in a code block for review.

  • When the driver is approved, I can just copy the code from the issue, or you can make a pull request with just one commit in it. If I commit the driver directly from the issue, a Signed-off-by line will be added to the commit message to credit the author.

Except for trivial patches, make an issue first before making a pull request too see if I agree with you. Only one fix/feature per commit and vice versa. I can commit simple changes directly from an issue, a pull request is not needed.

Clone this wiki locally