Development - notro/fbtft GitHub Wiki
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:
- Documentation/SubmittingPatches
- Documentation/SubmitChecklist
- Documentation/development-process/
- Mailinglist: Linux Driver Project Developer List
- Video: Write and Submit your first Linux kernel Patch
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.
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
Uselinux/scripts/checkpatch.pl --file fb_xxx.cto 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.