Wednesday, July 6, 2016

disassembly at repl?

I realize that "I just discovered something amazing about LISP that other people have known about for 30 years" posts can be kinda irritating, but I'm going to make one anyway.


Apparently in some (all?) dialects of common lisp, one can create a new function at the REPL, ask for its assembly at the REPL, and get the assembly for the function one just typed.


Check this out.


CL-USER> (defun snarf (n) (+ 5 n))
SNARF
CL-USER> (disassemble 'snarf)
; disassembly for SNARF
; Size: 39 bytes. Origin: #x100606317C
; 7C:       498B4C2460       MOV RCX, [R12+96]                ; thread.binding-stack-pointer
                                                              ; no-arg-parsing entry point
; 81:       48894DF8         MOV [RBP-8], RCX
; 85:       BF0A000000       MOV EDI, 10
; 8A:       488BD3           MOV RDX, RBX
; 8D:       41BBD0010020     MOV R11D, 536871376              ; GENERIC-+
; 93:       41FFD3           CALL R11
; 96:       488B5DF0         MOV RBX, [RBP-16]
; 9A:       488BE5           MOV RSP, RBP
; 9D:       F8               CLC
; 9E:       5D               POP RBP
; 9F:       C3               RET
; A0:       0F0B10           BREAK 16                         ; Invalid argument count trap
NIL
CL-USER> (documentation 'disassemble 'function)
"Disassemble the compiled code associated with OBJECT, which can be a
  function, a lambda expression, or a symbol with a function definition. If
  it is not already compiled, the compiler is called to produce something to
  disassemble."
CL-USER> 

Sunday, February 14, 2016

No more IR remotes.

At work I frequently program computers attached to banks of 9 or 12 HDMI screens, sometimes programming clusters of such computers to drive even larger display walls. At home, I only have one HDMI-compatible screen, but the array of small, cheap devices attached to it is growing by the minute. In each setting, the fact that these screens are designed to be controlled and configured via IR remotes is causing me a headache.

At work my IR-remote headache is that doing any sort of action to the screens (turning them on, turning them off, adjusting them) requires pointing the remote in such a way as to control one of them, but none of the identically-manufactured neighbors. For all I know, maybe there's a way to pair each one with a separate remote -- but then one would have to remember which remote went to which screen, and I doubt any such pairing would allow 45-way uniqueness. Our "solution" has been to try to avoid ever needing the remotes, and to stick a paper cup around the IR emitter so that the IR remote can be shielded from all but one screen at a time.

At home, I only have one screen I want to control, but to use it with any device I need to first find the thing I use to control the device (possibly a laptop or a smartphone) *and* the remote for the TV. Mostly I only need to turn the thing on/off, change the volume, and switch HDMI inputs -- but it'd be nice if I didn't have a separate remote I always lose for those actions

I can't be the only one facing these problems. Consumers seem likely to plug an ever-increasing array of strange devices into their home television sets, not all of which even come with IR remotes, while my belief that landscape of screens in the office environment will change radically enough to make this useful in the workplace is... ...something that I am implicitly gambling on in the "startup Lotto".

And it turns out the HDMI people thought of this already. So there is already most of a solution out there, called "HDMI-CEC" for "HDMI Consumer Electronics Control" (see Wikipedia's page on the topic). But, after fiddling with it, I cannot yet get it to do everything I want.

First off, I can't send HDMI-CEC signals over any HDMI connection from a discrete GPU from a (particular manufacturer of high-end graphics cards whose name starts with "nv"). The manufacturer, apparently, believes that HDMI-CEC is a consumer feature, and is not something their high-end cards should support. I beg to differ. I write software for walls of between 30 and 45 monitors and would like to be able to programmatically turn these monitors on, and apply things like "gamma correction", "color matching", "color temperature" and other settings. I would also like to do this on a per-program basis, so that one program driven by one set of designers/artists can have one set of monitor settings, and another program, designed by a different set of people, can have a different set of monitor settings. I'd also like to be able to individually address monitor settings for such a bank of monitors so that we can write our own software for calibrating them. Or, hey, so that some third-party can write software for calibrating large banks of monitors, and for storing the monitor settings in a way that allows us to programmatically re-apply them at any time. So, if anyone reading this works at a major graphics card manufacturer (particularly one whose HDMI outputs on their discrete GPUs don't support things like HDMI-CEC), please pass this along.

Second off, it is not clear to me whether HDMI-CEC is actually capable of changing all the settings I want to be able to change. Libraries exist that allow me to send commands for on/off, input selection and volume (although the volume for some TVs seems to only work if there is an external audio amplifier, which baffles me). But there seems to be a lower level of communication available which I have not fully sat down and understood. I don't know what this lower layer is capable of, I see some menu-related messages, but it is not clear what I can do with them. I suspect I should be able to record the sequence of menu actions required to apply a particular setting on a particular manufacturer, and play these back blindly, which means that it might be possible, albeit awkward, to be able to control any monitor setting reachable via the menu system normally accessed with the screen's IR remote. But it'd be nicest to have device-independent ways to set standard pieces of monitor configuration (color temperature, gamma value, audio volume) in a way that actually works, input selection in a way that I can figure out using the HDMI-CEC tools for the Raspberry Pi).

Update

It turns out that, if I'm willing to stick with nvidia hardware only, nvidia-smi and friends will do almost everything I need. And what it doesn't do, I don't need to do for the massive display arrays I deal with at work (I have no need to individually power monitors on and off there, audio goes over a separate channel, and I have no need for input switching)

For home use, HDMI-CEC remains just barely inadequate -- but, hey, maybe buying a newer TV (and an external audio system) would fix the problem.