devs: does anybody use /sys/mode?

  • /sys/mode is a legacy function that has basically been superseded by /grid/led/all. here's the docs:

    > /sys/mode i
    > where is one of:
    > 0 = normal operation
    > 1 = all LEDs on (test mode)
    > 2 = all LEDs off (shutdown mode)

    the difference is that /sys/mode is "sticky". when you set it to test or shutdown, you have to explicitly set it back to normal mode to make anything happen.

    the most recent devices (all of the varbright monomes and the arc) do not support it. all the other/older devices do. serialosc and libmonome still support it, but the lack of it on the recent devices means that we're deprecating it.

    i'd like to remove this in serialosc 1.1 but i wanted to check and make sure nobody's using it.

  • Never used it. (or seen it)

  • I have USED it. but i could deal with its absence.

  • decided to remove it.
    here's my justifications:

    /sys/mode is effectively a /grid/led command, except it's in /sys. yes, it has some other behaviors associated with it (the sticky property, in particular), but...

    the "other properties" only work on the non-varbright 64, 128, and 256es. it can be supported on the 40h, but currently isn't, and there's not even a facility for it on the varbright devices and the arcs, so it'd have to be emulated with other commands, which leads us to...

    anything you could do with /sys/mode you can do with /grid/led/all. it's effectively the same command.

    so that's that, it'll be gone in serialosc 1.1 (and monome_mode() is gone in libmonome 1.1). i'll detail this in the changelog when the final builds of 1.1 are available.

    if you're asking "why?", it's because this was the only libmonome command that had to be implemented no matter the device, which irked me when i realized that it's basically an output command just for grid devices. after removing it, the only mandatory functions for implementing a new type of device in libmonome are the i/o functions (open, close, free) and the event handler. everything else is optional.

    just doing my part to keep the API clean so that people don't stumble across the "mode" command in like 5 years when we have 3D monomes or whatever and go "hmm what's this thing even *do*?"

  • i fully support this decision.