On Thu, Jun 17, 2010 at 05:48:12PM +0300, Alexia Death wrote: > Im looking for pointers on how to set up a sane testing environment > for any driver testing. Having to stop whatever I do in my X and kill > it to load the updated driver, that might be badly broken and kill X > does not seem to be the sane way and Im too attached to my X to do the > actual development in shell with emacs... > > What I have to work with is the default X install that comes with > Lucid and that's it. Any pointers on how to rig things sanely would be > immensely welcome.
whether you consider the following "sane" is a different matter but this is my setup: - I use vim in a terminal, with a keyboard shortcut to start terminals. So it takes me less than 10 seconds after long to get back into hacking. - I use zsh with history and autocompletion. so I don't type things like cd xorg/drivers/xf86-input-wacom, I just type CTRL+R xf86 ENTER. - I have a ctags and cscope setup, both locally per project and globally for important headers. Which means I jump around between repositories like the server and the driver without ever leaving vim. - I have aliases to all the commands that I use frequently. "m" for make (arch-specific alias, I use the same source tree for i686 and x86_64), "rbs" for git rebase -i, "rbc" for git rebase --continue, "amend" for git commit --amend. - shellscripts for common tasks (gitsend.sh as a wrapper around git send-email, etc.) - mutt for email. all that has a learning curve but the benefit I get from it is that it is incredibly fast and that no matter where I am, as long as the environment is the same, it doesn't even matter if an X server is running. kms has helped with this a lot, since even when X is broken I get a sane resolution now. anyway, the above is my hacking setup. for testing and debugging: - I do actually zap my server to test things. since gdm will restart it for me and I'll back where I was a few seconds later that' works great for me. - If I really screw up and the server keeps segfaulting, I move over to my other machine, ssh in, switch to runlevel 3 and start X through gdb (or attach it to the running server). This is the main lesson here: have two computers. otherwise you can either say goodbye to debugging or your sanity, whichever comes first. - gdb almost always runs in a screen session, so I can just fix the code through ssh, install it, test until it works. then I switch back to runlevel 5. - in 90% of the cases, finding a bug with gdb is faster than with the debuglevel options, so keep your debugger handy. I hardly ever use printfs or debug statements myself. mind you, I've got an unfair advantage, I work on this stuff every day for several hours so it's mostly muscle memory for me. for occasional developers, it's not quite as easy. Finally, I work with the current git tree of the X server. It installs into /opt/xorg (along with the wacom driver) and I have a symlink from /usr/bin/Xorg to /opt/xorg/bin/Xorg so that gdm restarts the right server. if the server is _really_ broken, I just change that symlink to the system Xorg binary and go from there. So I usually don't modify my system install when hacking on the driver, gives me an escape hatch if things go bad. hope that helps a bit. as I said, "sane" or not is a different question, it works for me. Cheers, Peter ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
