And by using an USB extension cord, it, too, has an acceptable range, so I could actually use it for something… if I figured out what I could use it for.
I mean, it only generates two keystrokes:
Page Up if you hold it this way and click…
I should trim my nails
And Page Down if you hold it this way and click.
Or the other way around. I forget.
If you just put it on a table and click on it, it decides that it wants to be a mouse instead, so the click turns into a mouse click, which is definitely not what I want.
Hm… but I do have gaffa tape. I wonder what’ll happen if I just gaffa the sensor on the bottom.
Elegant!
It works! So it can be used as a single purpose HID button. If I had something where that would be useful, and that didn’t use the Page Down key for something else.
Or… I could perhaps just use the event remapper thing from the previous post, come to think of it. But I don’t really have any projects that would require such a button right now, so back into the Cupboard Of Mystery it goes again.
I apologise for besmirching Logitech’s, er, good? name.
I’ve had a Logitech diNovo Mini as my TV computer keyboard for a few years. It works as well as you’d suspect a wireless keyboard to work: It loses contact with the receiver a couple of times a month and needs to be switched off and then on again, but otherwise it’s OK. Doesn’t lose too many keystrokes.
Logitech diNovo Mini
But it’s starting to fail mechanically, I think. The larger buttons (Enter, Del, etc) now only work if I press them… just… so…
I looked around for new media keyboards, but they’re either too big, or unusably small. This was kinda just right. So I went off to eBay and got a couple of new old ones.
At least that’s what I thought I bought. Instead I got a couple of Lenovo TV730 keyboards, which is apparently also called Logitech Mini Controller.
Logitech TV730
See? Very similar.
And here my troubles began. This Logitech came with a different, smaller receiver:
Much small
The receiver works fine under Linux, but I could only get about two meters range. (That’s seven microfurloughs in Imperial measurements, I think.) But I had it plugged in like this:
I should wash those grease stains off the front
After bitching about this on IRC a bit, I tried using an USB extension cord. Like this:
Very finger
And then I got, like, an 11 meter range, through two (pretty light) walls! So the metal in the computer case messed up those radio signals or something? Ok, we’re on! This is doable!
And then I discovered that some of the keys don’t work in Xorg. In particular, the PgUp and PgDown keys give exactly zero X events, according to xev. That’s no fun.
key/402? That’s a suspiciously high number. And duckgoing around shows that this is a well-known ancient X problem: X can’t deal with events that has a numerical value over 255.
This was reported as a bug at least as early as 2007, and apparently they (sort of) started working on it. But they didn’t fix it. Instead this very nice person wrote a simpler fix that allows you to just remap these problematic keystrokes into other keystrokes. Yes, it’s a hack, but if you’re not going to provide a real solution in 8 years, I think it might be better to just include the hack, don’t you think?
Obviously the Xorg people didn’t, so you still have to build your own evdev_drv.so. The link up there has good instructions on how to build and install this driver into your X, so I won’t repeat that.
For my device, I put the following into my /etc/X11/xorg.conf:
However, it’s not totally unproblematic. If I pull the receiver out and then put it back in again, X will sometimes not believe that it’s been inserted:
[3275248.027] (**) Logitech TV730: Applying InputClass "evdev keyboard catchall"
[3275248.027] (II) Using input driver 'evdev' for 'Logitech TV730'
[3275248.027] (**) Logitech TV730: always reports core events
[3275248.027] (**) evdev: Logitech TV730: Device: "/dev/input/event9"
[3275248.027] (WW) evdev: Logitech TV730: device file is duplicate. Ignoring.
[3275248.032] (EE) PreInit returned 8 for "Logitech TV730"
I posted yesterday about my extremely useful Youtube-based weather monitor not working properly any more. I thought Google had changed the video format or something — refusing to play videos when using mplayer.
After adding more debugging to the script that runs the monitor, that turned out to be incorrect.
Here’s the search result for a song by Dollboy:
Searching for Dollboy+The%20Ventriloquist (200)
Duration: 236 (https://youtube.com/devicesupport)
Duration: 232 (Puppet Dancing in South Africa)
Duration: 324 (Ventriloquist Dummy Creepy Doll Makeup Tutorial)
Duration: 449 (Creepy Broken Doll: Hair, Makeup, and Costume Tutorial!)
One of the results in the search is the “unsupported device” video! And my script would pick that video if it’s the one that has the most appropriate duration. And it seems to be in the result set for any searches:
[larsi@potato ~]$ ./src/flutter/flutter "" "foo"
Searching for foo (200)
Duration: 245 (Foo Fighters - In The Clear)
Duration: 236 (https://youtube.com/devicesupport)
Duration: 271 (Foo Fighters - The Pretender)
So this is just Google’s way of saying that their old search API is being phased out? I’m using the
API. And this seems to be the case: The API v2 is being discontinued. The v3 API requires an application ID, and it’s more JSON-ey, but it looks like it should provide the same functionality as the v2 API.
It’s nice of Google to notify the users of the v2 API that this is happening, I guess, but it would have been nice if the video said something about the API instead of just saying that the device was unsupported.
I’ve been using youtube for really useful things for a few years. On April 20th, the following video started to appear instead of the ones I wanted:
I get this for about one third of the videos — the rest play fine, as before.
So it’s saying that I’m viewing Yotube with an unsupported device. Which is probably fair enough. I’m searching youtube via the API, getting an URL via youtube-dl, and then playing the video with mplayer under Linux. Neither really sounds like what Google would call a supported device.
Devices affected: Select devices manufactured in 2012 and earlier, including Sony TVs & Blu-ray Discs, Panasonic TVs & Blu-ray Discs, older iOS devices, and devices running older versions of Google TV.
So Google says that three year old TVs are too ancient to watch their content. Fine. Who cares about three year old TVs, anyway?
But does anybody know how to make mplayer support whatever the new format is? Or is this part of Google’s ever present drive to wall their gardens?
I’ve binged for an answer, but haven’t found anything promising…
In November 2014, Emacs switched version control systems from Bazaar (aka bzr) to git. There were two main reasons: 1) bzr has kinda stopped development, and 2) using a version control system that more people are familiar with might attract more developers.
On the other hand, git is really, really finicky, and bzr is arguably superior to git in many works flows. Perhaps switching to git would scare away some Emacs developers who just couldn’t be bothered?
First of all, it’s amusing that we have a timeline going back to 1988, but I would suspect that the numbers before, say, 2007 are too low because maintainers would commit patches with themselves as the “author”, I think. (Edit: Eli Zaretskii says the numbers should be accurate throughout the timeline.)
But the most recent years should be kinda reliable:
Uhm… Well, attracting droves of new developers didn’t happen, apparently. Except for the spike the month git was introduced, we’re within the normal range of developers, I think.
Anything interesting pop up if we count commits per month instead of contributors per month?
Not really — same story.
What about the number of people who commit patches to the Emacs repository?
That does look like a possible uptick.
So… was the changeover worth it? Probably. But the impact was a bit over-sold on both sides, I think.
Page Up if you hold it this way and click…
