First step in kernel development

I wanted to work on linux kernel from some time, but didn’t really know where to start. One day a wise man told me “a good way to learn is to do it! So get an USB device and write the driver for it.” I answered: “Well I didn’t thought of that, usually I’d use libusb for such cases.”

A USB device

Some days later, I didn’t find any nice device, but I thought, why not building it as well?
As I already told you, I’ve already hacked out an USB device: USBtinyISP. So I got back to the original code: usbtiny and I build myself a small device with 4 LED and 2 buttons:

My prototype's picture

I didn’t use and ATtiny, but an ATmega8 to keep more room for future improvements 😉 (The ATtiny2313 is already full with the USBtinyISP code).

And here is the schematic: (as picture, the gschem sources stay in git under the sch folder):

The schematic

Once the wiring done, some few lines of code based on the usbtiny sample, and that’s it: A firmware for the ATmega (in the root of the project).

Then I needed to test it, so back to the first idea, some code lines using libusb, available in the test, helped to improve the firmware 😉

Everything’s OK, let’s write a driver.

The Linux driver

Well I just followed some tutorials:

Finaly looking at the usbled.c file in Linux sources to get some more updates.

This build a module that adds the files leds and keys in the device folder that Linux creates in /sys/bus/usb/.

That’s it! I don’t know if you learned something, but I did learn a lot! 😉

All source code are available under GPL2 or GPL2+ on my gitweb: jvdg_usbgadget.git

As for the egocentric name, it’s just to avoid any name conflict. This has no mean to be integrated anywhere anyway. (The device uses an USB ID reserved to prototyping, so unusable for products…)

Triage X Bugs of the Week (TXBW12)

This report is 2 week late… It was delayed by an important event, not the release of squeeze, but the birth of my first child: Célestine is born Monday the 31th of January.

My wife and Célestine are both fine now but the firsts days were not that easy. I’m starting to recover from the lack of sleep, but I’m still very late on my debian tasks 😉 So I guess I just drop Triaging for week 13, 14 and maybe 15…

Now the bugs I triaged just before :

  • #509489 ping & merge with #492783 – Switching from tty to X by pressing Alt+cursorkey pass cursorkey keypress to X. OK for this user, waiting for more responses on other merged bugs…
  • #515546 ping & closed – keys stick when switching consoles.
  • #369202 ping – randomly activated ‘access keys’.
  • #547143 ping, it’s udev now, not hal – xorg/evdev/HAL versus serial mouse – submitter said serial devices should be handled using inputattach. I think It’s been added to some docs but didn’t take time to look at it.
  • #547888 ping & closed by submitter thanks! – high CPU usage in X.org server after some time.
  • #489996 mail error, closed – problem auto-detecting / selecting some modes.
  • #550124 ping & closed – some modes aren’t recognized.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of 2011 first Weeks (TXBW9-10-11)

I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !

The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !

I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉

  • #451708 ping & close – xserver-xorg-input-synaptics: Option “GuestMouseOff” “true” not working.
  • #424743 ping & forwarded – X11 pen driver doesn’t work on tabletPC Fujitsu Stylistic 2300 (fix included).
  • #499664 ping, try nouveau – X fails to start with xserver-xorg-video-nv 1:2.1.12-1.
  • #512614 confirmed & upstream – xset dpms rejects reasonable values as illegal.
  • #512711 ping and later closed – All keypresses repeated roughly three times each, makes login impossible.
  • #513128 ping – X server crashes every time when gnome-screensaver starts.
  • #486356 merge with #482592 – numlock led is inversed (using numlockx) .
  • #515737 ping & closed – After upgrading from Etch to Lenny, mouse pointer is very slow and keys don’t repeat.
  • #515840 ping – Desktop is not using full screen after upgrade from etch to lenny.
  • #516860 closed after looking at the git history – Xorg with ‘-sharevts’ use almost 100% of the CPU.
  • #362434 ping & closed, suggested to try nouveau – nv has problems with xcursor-themes.
  • #502131 ping & closed – System gets into a `state’ and fails to process modifier keys.
  • #453296 closed (old ping unanswered) – MacBook: cannot assign right mouse click to lower Enter key.
  • #504537 ping – X server eats CPU on sparc.
  • #502313 ping – Applications are getting “ghost” Alt keypress events, but I press no keys.
  • #527118 ping – autoadded input devices kill X server.
  • #270887 forwarded – startx and xinit do not preserve client arguments.
  • #542542 closed after looking at the git history – non-VGA compatible graphics devices won’t run X.
  • #492888 ping – xorg ignores keystrokes.
  • #543210 merge with #492783 – Alt-F7 to return to X, passes F7 key to top focus’d window.
  • #524413 closed – xauth fails with xorg 7.4, this was actually an xinit bug and the git log lead to #549377 being closed…

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triaging bugs is not that hard !

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!

Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.

The available triaging docs

The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o !

Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉

Talk with the maintainer(s)

Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.

My current process

This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!

  1. List bug from UDD: XSF unstable bugs sorted by date.
  2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
  3. Read the report, don’t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
  4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it’s not that often that I have something to test).
  5. Decide what to do, most of the time, I will ‘ping’ the submitter.
  6. I’m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
    So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
    The triaging procedure suggest to ping -submitter, but using mutt it’s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
  7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
  8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
  9. When the submitter answers, just react accordingly, if the bug can be closed, then close it ! 😉
  10. If after some time, the bug are still not answered, consider closing them (I haven’t started that yet, but this will probably get the bug number down faster:) ).

Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉

To submitters, please keep the bug CCed when you answer, thanks.

For the skeptics

Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉

Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.

Conclusion

As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉

Get involved !

Triage X Bugs of the last 2010 Week (TXBW8)

Happy new year !

  • #440495, #437255 ping – Keyboard steal after stopping touchpad.
  • #476143 Closed: submitter never answered Brice’s request – xserver-xorg-video-nv: Driver reports wrong display size.
  • #468331 ping – xserver-xorg-input-kbd: xorg.conf okay, no AltGr though but “setxkbmap -variant nodeadkeys de” works.
  • #498210 ping – xserver-xorg-input-kbd: ctrl:nocaps keycode 66 is on both the control and shiftlock modifier list.
  • #488685 ping & close: hardware not available anymore – xserver-xorg-input-kbd: Acer TravelMate 2303M : the ‘Fn’ key is inverted.
  • #511910 ping – xserver-xorg-input-evtouch 0.8.7-3 does not work with HAL.
  • #513297 close – x11-xkb-utils: When I use the setxkbmap command i get the following error: Error loading new keyboard description.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Christmas Week (TXBW7)

For some reason1 bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn’t write to me, this bug will have waited for what… about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort 😉

  • #607242 reassign & give+ask moreinfo.
  • #403350 ping & try nouveau – xserver-xorg-video-nv: xset dpms force off does not turn off the backlight.
  • #469104 config suggestions & close – xserver-xorg-video-tdfx: screen resolution too low.
  • #476198 closed – xserver-xorg-video-radeonhd: Cannot turn on a secondary screen without restarting X (xrandr-related problem).
  • #492783 ping, unreproducible – vt switch key combination leaks to clients.
  • #496150 ping – xserver-xorg-core: shutting off monitor messes up display.
  • #504104 ping & closed – xserver-xorg-input-mouse: Emulate3Buttons stops working from time to time.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail.

Triage X Bugs of the Week 6 (TXBW6)

An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875…

  • #471423 ping – ati driver ignore Option “Enable” “false” in monitor section, but accept the undocumented Option “Disable” “true”.
  • #468561 ping & closed – vesa: switching resolution with xrandr after suspend-to-ram.
  • #447526 ping – memory leaks.
  • #475534 closed – as reported said, oclock seams to work correctly…
  • #466044 ping – xserver-xorg-core: internal screen of laptop with external screen attached not blanked when laptop closed but still in use.
  • #482317 ping – libxt6: scroll list overflow in gv.
  • #425814 ping – xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Week 4 and 5 (TXBW4-5)

Last week I was too busy for the triaging work, so I did more this week… Anyway there are still some 871 bug candidate for triaging, so again, any help would be appreciated !

Also I’d like to thank again people giving me cheers and advices when they receive my pings 😉

The buglist now:

  • #419986 ping & close – server lockups related to dri.
  • #415588 ping – modelines are ignored.
  • #417601 ping & close – mga dri issue.
  • #439357 closed – 3 year old install issue… Not relevant anymore…
  • #377847 ping – nv driver: No way to set 1600×1200, apparently it works with nouveau.
  • #449039 ping – crash with too many remote clients.
  • #440880 closed – 3 year old, user never replied.
  • #457440 ping – ctrl-alt keyboard combinations ceased working after prompts by ratpoison.
  • #413691 ping & closed – arrow keys sometimes produce repeated digits.
  • #451537 ping then closed by submitter – Can no longer scroll up/down with edge of touchpad.
  • #437254 ping – touchpad issue, at first the reported tried to hack out a patch…
  • #444183 ping – macbook xserver-xorg-input-mouse: Vertical scrolling doesn’t work anymore.
  • #445625 ping: try nouveau? – crash with nv driver and dual head configuration.
  • #428091 ping – Display has wrong colours and is offset (in 16bpp only).

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Week 3 (TXBW3)

This week it has been harder for me to start on this… but KiBi’s post Debian XSF News #1 pushed me to continue. Thanks for the cheers!

  • #331637 ping – Xrandr disabled while Xorg log says the opposite.
  • #321357 tagged wontfix – xset behaves as intended, there is no easy way to set keyboard autorepeat for single key…
  • #242442 close – xclock -rv looks visible to me.
  • #427346 close – was already tagged unreproducible, I couldn’t reproduce it either so I closed it.
  • #169239 ping – 8 year old wish… probably too late ?
  • #431449 ping – xmodmap errors when launched by keyboard shortcut.
  • #202923 close – xorg has timestamps in server log messages.
  • #252214 tagged wontfix – Andrew Pimlott (reporter) said “This bug probable needs a NOBODYCARES tag. :-)” so wontfix will do it.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Week 2 (TXBW2)

Hey, one more week !

  • #418377 – ping & closed (default X resolution for etch?! installation).
  • #419960 – ping & closed (submitter screen apparently does not support DPMS).
  • #409337 – ping (Xorg/Gdm vertical refresh config).
  • #389030 – closed (boot with no usb mouse now work !).
  • #309226 – ping (xnest crash, seams fixed now).
  • #397438 – ping (dual monitor on old ati driver).
  • #414275 – ping, user can’t test it any more, so closing.

Well my UDD query report 879 bugs today… not a great improvement since last week… if more bugs are opened than I can close, I’m not going to make it alone !

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.