I think that the time out is probably unneeded. we can do anything based on whatever number of participants there are. currently we are only checking for two states: one user in the chat or more than one user in the chat. we could easily expand this in all sorts of ways. given the information that we have. we could also consolidate the logic of the time out and the participants in the chat into this one area of code and have all of the conditions that we might want. we can react to whatever conditions in this one. place now and later we could have a separate central server that holds the state and the chat room could just be one of the sensors that provides information about the conditions/ state of the sudo room.
hey it seems like maybe handleParticipantChanged() only gets called when
someone joins or leaves the room... is there a way to call it when we join the
room in the first place? Because what if the monitor state isn't what it
should be and we join... we won't know to correct the situation until someone
joins or leaves?
actually i know this seems annoying since we've already hooked into an API
event, but presently the DPMS timeout is set to 300 seconds. That means that
the screen is supposed to blank if there's no "activity" like moving the mouse
around or hitting a key on the keyboard.
It seemed to me like Chromium or the jitsi window was disabling that...because
I wasn't noticing it blanking even though there was no keyboard/mouse
activity...but maybe that's changed, in which case it will blank after 5
minutes even if we've turned it on explicitly (for example when someone joined
the room)
Should I fix this by disabling the timeout? Then the monitor state will stay
the same until it's acted upon by an external force. But then if there's
nobody in the jitsi room (which will unfortunately be most of the time) if
someone plugs in a keyboard/mouse (they will) and wakes up the screen...it will
stay on indefinitely. That's not ideal.
I think i'd rather keep the 5-minute timeout, and just get the javascript thing
to check every five minutes (and upon startup) whether there are enough people
in the room to keep the screen on, in which case it pokes the screen-on
it would even be OK to just not tell it to turn off anymore at all, since the
timeout would take care of that. This would be good because you can imagine
cases where someone leaves the jitsi chat for a few seconds and rejoins, we
don't need to power-cycle the monitor's backlight unnecessarily if they're
coming right back.
What do you think? awesome work by the way!
-jake
On Sun, 16 Jan 2022, ruin mechanic wrote:
> Recycle, Reuse, ReDuck!
>
>
> On Sun, Jan 16, 2022 at 6:56 PM Jake via sudo-discuss <
> sudo-discuss@sudoroom.org> wrote:
>
>> yes it's awesome! log in and look at sudoroom anytime here:
>>
>> https://meet.waag.org/turtlesturtlesturtles
>>
>> if it's dark, it probably means nobody is there and the lights are off and
>> the
>> planet is blocking the sunlight, but if you wait no more than 12 hours, the
>> planet will turn and sunlight will stream in again, illuminating the room.
>>
>> Also, hackers will appear and you can talk to them and try to entertain
>> them!
>> Both hackers appearing in person in sudoroom, in view of the telescreen, as
>> well as other hackers connecting to the jitsi room from wherever they may
>> be.
>>
>> what Matty said about the client app is only 90% of the new innovation, the
>> last bit is my contribution; a python web server which allows the custom
>> web
>> app to turn the telescreen on or off, depending on whether people are in
>> the
>> jitsi "room" with it:
>>
>> https://github.com/jerkey/ducks/blob/dpms-control/server.py
>>
>> it's just copied over from a web server to open and close a duck coop door
>> (get
>> it...WEB server because ducks have WEBBED feet) with a few changes to
>> actually
>> turn the monitor power on and off through DPMS.
>>
>> so join the chat and join in the hacking! it's social and fun and safe!
>>
>> -jake
>>
>> On Sun, 16 Jan 2022, ruin mechanic via sudo-discuss wrote:
>>
>>> Rejoice in the hacker wizardry of the new Telepresence Portal
>>> Jake and I wrapped it up today and hackerspace futurism has been achieved
>>>
>>> the monitor will turn on if any Sudoers join the jitsi chatroom
>>> and it will shut off if everyone leaves the chat
>>>
>>> here is the source for the chat client app powering it
>>> https://github.com/sudoroom/jitsi-telepresence-portal
>>>
>>> hooray!
>>>
>>>
>>> -matty/interrupt
>>>
>>> On Sat, Jan 15, 2022 at 11:50 PM Jake <jake@spaz.org> wrote:
>>>
>>>> wow, this has progressed a lot!
>>>>
>>>> tonight, in the jitsi chat, which is here:
>>>> https://meet.waag.org/turtlesturtlesturtles
>>>>
>>>> matt and me (to the entertainment of everyone passing through sudoroom
>> and
>>>> working in there) have been chatting and co-hacking, and i've been
>> learning
>>>> npm/node/react web stuff.
>>>>
>>>> basically we installed the jitsi SDK repo and ran it, and then hacked it
>>>> to go
>>>> to the meeting room we've been using instead of the default setting -
>> and
>>>> now
>>>> we're adding a function to it to automatically control the screen power
>>>> (screensaver) depending on whether someone is in the "room" or not.
>>>>
>>>> we're also sharing a tmux window in the machine (the one controlling the
>>>> big
>>>> TV) and teaching each other lots of stuff. And neither of us are
>>>> physically in
>>>> the space!
>>>>
>>>> It's the most exciting saturday night i've had in a long time!
>>>>
>>>> If anyone else is interested in this kind of social hacking, speak up
>> and
>>>> i'll
>>>> ping you if it happens again. Or just join the jitsi room (linked
>> above)
>>>> and
>>>> leave it open until someone starts talking to you.
>>>>
>>>> last night (friday night) we had a bunch of people join the chat!!!
>>>> including
>>>> a couple of people who randomly hadn't seen each other in almost 5
>> years!
>>>> It was basically a party, including whoever was in sudoroom, and like 6
>>>> different people who rolled through the jitsi chat.
>>>>
>>>> -jake
>>>>
>>>> On Sat, 15 Jan 2022, Jake wrote:
>>>>
>>>>> awesome! I believe this is what Matty is working on too
>>>>>
>>>>> https://github.com/jitsi/jitsi-meet-web-sdk
>>>>>
>>>>> that was so much fun with everyone talking to each other tonight!
>>>>>
>>>>> -jake
>>>>>
>>>>> On Sat, 15 Jan 2022, Marc Juul wrote:
>>>>>
>>>>>> On Wed, Jan 12, 2022 at 11:54 PM Marc Juul <marc@juul.io> wrote:
>>>>>>
>>>>>>> On Wed, Jan 12, 2022 at 1:37 AM Jake wrote:
>>>>>>>
>>>>>>>> I've set up a jitsi terminal on the wall in Sudoroom!
>>>>>>>>
>>>>>>>> It's a big TV made by Hitachi, and it has a feature where it can go
>>>> into
>>>>>>>> "power saving" mode when the HDMI signal is lost. That means the
>>>> screen
>>>>>>>> can power down when DPMS puts the monitor to "sleep". It has a
>> webcam
>>>>>>>> that's clearly labeled, and on a hinge so it can easily be aimed
>> down
>>>> at
>>>>>>>> the floor if people are shy, and it has a Jabra USB
>> speaker/microphone
>>>>>>>> thing which should hopefully provide good speakerphone
>>>> functionality. I
>>>>>>>> have the computer setup to start firefox, and i have firefox set to
>>>> open
>>>>>>>> the jitsi page, where permissions are already enabled for
>>>> webcam/audio.
>>>>>>>> The only remaining need is to automatically wake the monitor from
>>>> sleep
>>>>>>>> (using "DISPLAY=:0 xset force dpms on") whenever there is anyone
>> else
>>>>>>>> detected in the jitsi "room"
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I wrote a short program that can trigger a command based on
>> downstream
>>>>>>> bandwidth usage:
>>>>>>>
>>>>>>> https://github.com/sudoroom/bw-trigger
>>>>>>>
>>>>>>
>>>>>> So it turned out that the library I used doesn't really work for UDP
>> :/
>>>>>>
>>>>>> The correct solution is definitely to have a client that joins with
>>>> XMPP.
>>>>>> Information is sparse but I found this code that I believe is for
>>>>>> stress-testing that should be modifiable into what we need:
>>>>>>
>>>>>> https://github.com/jitsi/jxs
>>>>>>
>>>>>> Relevant code in:
>>>>>>
>>>>>> https://github.com/jitsi/jxs/blob/master/src/Participant.js
>>>>>>
>>>>>> --
>>>>>> marc/juul
>>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> sudo-discuss mailing list -- sudo-discuss@sudoroom.org
>> To unsubscribe send an email to sudo-discuss-leave@sudoroom.org
>>
>
_______________________________________________
sudo-discuss mailing list -- sudo-discuss@sudoroom.org
To unsubscribe send an email to sudo-discuss-leave@sudoroom.org