Trigger browser reload in Enlightenment
$ browserReload yourbrowser
BROWSER="vivaldi"
function BrowserReload()
exec "silent! !browserReload"
redraw!
endfunction
map <F5> :call BrowserReload()<CR>
Opera is dead!
Simple, flexible and powerful
Themes
Extensions
Conclusion
Vivaldi
deb2tgz 1.0 XZ and slack-desc patch
So I was trying install the new Opera for Linux which unfortunately is offered in Debian package only... deb2tgz to the rescue! Well that failed miserably since the new .deb also allows for XZ data which isn't supported by deb2tgz. So after some scripting (i.e. more or less completely rewriting it) I managed to repackage Opera into .txz.
Here's the patch for deb2tgz so it support XZ... it also completely repackages the data and adds a nice little slack-desc description file. It's been tested with Opera and Skype (...) and the initial results look promising... that said, let me know if you have any packages that break.
Fun fact: Opera doesn't really start...
Roland TD-15 MIDI read/write
It seems I had a request recently to improve my Roland TD-15 hack. And since I'm such a nice guy *cough* I figured I'll have a go at it... and behold the new version! It's pretty similar to the old one except that it now not only sends from the Roland to MIDI but also the other way around, i.e. it's "read / write".
Unfortunately the development didn't went as smooth as I hoped. Conceptually it was quite easy, just read from the MIDI device and pass that to USB via bulk data. The first annoying but was the fact that some programs send MIDI data in a somewhat shortened version which means you can't pass it directly but it needs some conversion.
However that wasn't the bit I struggled with... reading from both MIDI and USB at the same time was. The first attempt was to fork the process and read USB in one process and MIDI in the other. While this worked in principle, it caused a weird issue, namely that the USB reading process would catch the result of the other process writing to the USB port. Which in turn locked up the device causing nothing to happen after that. What I don't get is that windows manages to send to the USB while listening to it uninterrupted. So probably the reading process is paused during the write... then again I haven't managed to convince LibUSB to do so...
Anyway as a result it's now a "polling" based driver which continuously checks the MIDI and the USB devices for new data and handles it accordingly. The obvious result is that it causes a somewhat heavy load and lags (a little)... then again I played around with Renoise and my TD-15 and I'm actually quite pleased with the results!
Enjoy, and keep the feedback coming!
Roland TD-15 and Linux
I upgraded my box recently which came with a nice new Linux kernel. And after a reboot (prolly 2 weeks later) all of a sudden this line showed up in lsusb:
Is it really so? Does Linux recognize my TD-15? Yup... unfortunately that's pretty much it, i.e. it doesn't actually support it. Which is obviously quite a pain in the arse. However with my recent USB reverse engineering experience I figured I can crack this puppy as well! So I did.
Now before you all get too excited, for now I've only been able to get the MIDI part to work. Which is the easy part but I consider this a step in the right direction. As a matter of fact I'm planning to go all the way (i.e. sound in+out) with this so the TD-15 can actually be fully supported by ALSA. But I will probably need "some" help with that since I've got no experience with ALSA (i.e. feel free to leave some comments!).
Like the previous exercise, I used a windows VM with the driver and wireshark to see what windows was doing to that poor USB port. As it turns out, not that much, the initiation is fairly simple and after that it's just receiving bulk data. There are 2 additional "interfaces" available which presumably are the sound in+out but, as stated, I haven't figured those out for now.
Using the hack
Getting this puppy up and running is similar as with the Cyborg volume bar, download the source, run "make" in the "roland-td15" directory and run the roland-td15 binary that's produced (yes, you need root).
When started without any arguments it will try to connect to the TD-15 and if successful it will spit out the raw MIDI values. You can start it a MIDI device name (e.g. hw:3,0) which will cause it to write the MIDI command directly to that device. There is also and optional 2nd argument "skipOffs" which skips the "off" MIDI commands. To start, simply run the following (don't forget to modify /etc/sudoers!):
So far I've had success with the ALSA Virtual Raw MIDI device:
Dir Device Name
IO hw:3,0 Virtual Raw MIDI (16 subdevices)
IO hw:3,1 Virtual Raw MIDI (16 subdevices)
IO hw:3,2 Virtual Raw MIDI (16 subdevices)
IO hw:3,3 Virtual Raw MIDI (16 subdevices)
If it doesn't show any Virtual device try loading the driver:
That's it for now, hopefully I got some more updates soon!
Cyborg V.7 volume bar on Linux
While playing with the Cyborg V.7 macro keys I though: how hard can it be to get the volume bar working on the keyboard as well? As it turns out, not too hard.
The big difference is that instead of reading what happens on USB, you'll actually need to write to USB to change the volume bar leds. So I started to play around with LibUSB, grabbed some scripts and monitored what windows did on my USB port when adjusting the volume bar via the "official" driver.
The end result is a wee piece of C code that sends a signal to the relevant USB device (06a3:0728) and you're done. You can download the code here, untar it, go into the cyborg directory, run make and if all goes well you should have a binary called "cyborgLeds".
Just run this binary as root with a argument 0 to 20 and it'll change the volume bar on your keyboard:
To run as root, add the following line to /etc/sudoers:
BTW, reverse engineering windows drivers actually became a lot easier with virtual machines. Get a windows VM up and running on a Linux box, attach the relevant USB device, start usbmon, use wireshark or just cat the usb device (cat /sys/kernel/debug/usb/usbmon/0u) to monitor what windows and the device are doing to each other.
Cyborg V.7 macro keys on Linux
I bumped into some scripts recently that nicely abuse usbmon to watch actions on USB devices and do stuff with it. And guess what, this works nicely to get the Cyborg V.7 macro keys to work under Linux!
I wrote a little bash script (cyborgMacros.sh) which monitors all usb traffic for a certain pattern and if found sends out a Control+F1 to Control+F12 mapping to Xorg. Which allows you to map the macro keys in pretty much any application.
Unfortunately in order to actually monitor USB you'll need root access so you're probably best of to sudo the script on login. Just add the following line to /etc/sudoers:
user ALL=NOPASSWD:/path/to/cyborgMacros
Another shortcoming of the script is the fact that it monitors "usb device 0" which basically means all USB traffic is passed through this script (I'm guessing this could have quite a performance hit). This is just because I've been too lazy to add some keyboard detection in it... hopefully I'll get around to fix it sometime.
Lastly it requires xdotool to be able to send the keyboard events to Xorg. I think it's included in most distro's but if not you might need to grab it yourself.
Long story short, just start the script as root and off you go!
Cyborg V.7 and R.A.T. 7 on linux
So about a year ago I bought some new kit since my old keyboard and mouse were pretty much in the crapper. I'd been searching online for some cool, yet functional, stuff and ended up buying these little gems:
Both look pretty cool and work like a charm, or at least if you're running windows, install the drivers and dick around a bit. Linux however is, as usual, another story since it's apparently very hard for hardware vendors to write a driver for Linux. Having said that, it's not as bad as it seems, both are in the basics just normal input devices so they're support but with some limitations.
Let's start with the keyboard, obviously the normal keys work, and so do the special audio specific keys. As a matter of fact, because the cool stuff (aka game mode) is handled within the keyboard, this works perfectly as well. And the best feature of all is the fact that game mode disables the "Windows key"!
So what doesn't work then? Well you have 12 additional macro keys (C1 to C12) on the sides of the keyboard. Since Cyborg decided it was fun to require a driver for this, you're pretty much screwed under Linux (tho I did find a solution for this...). Then there is the cute volume bar on the keyboard which unfortunately also requires a driver to actually control this so, again you're fucked under Linux. However for normal usage this keyboard really works just fine under Linux, unless you want the macro keys and the volume bar to work. But again more on this later.
And what about the R.A.T. you ask? Well that works like a charm except for the fact that the (shitload of) extra buttons aren't mapped by default. Which is actually easily resolved by telling Xorg to map them. There's a bunch of instruction floating around on the Internet but obviously I chose to do my own mapping.
Just open "/etc/X11/xorg.conf" and add the following section and off you go:
Section "InputClass"
Identifier "R.A.T."
MatchProduct "Saitek Cyborg R.A.T.7 Mouse"
MatchDevicePath "/dev/input/event*"
Option "Buttons" "17"
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 0 0 0 16 17"
Option "AutoReleaseButtons" "8 13 14 15"
Option "ZAxisMapping" "4 5 10 11"
EndSection
Concluding this is cool stuff and if you're considering buying it, do it! And if you're on Linux and you can live without the specials (for now), it's also definitely worth it.
More to come!