LCDproc development and user support list

Text archives Help


[lcdproc] My patchs at last


Chronological Thread 
  • From: glen AT antefacto.com (Glen Gray)
  • Subject: [lcdproc] My patchs at last
  • Date: 11 Jun 2001 09:57:58 +0100

On 08 Jun 2001 13:13:09 -0700, Philip Pokorny wrote:
> So you got some timeout to do some timeout code... Was that pun
> intended? [grin]
>
Ha ha, very funny. No it wasn't intended but well spotted :-D

> If you've got CVS, you can use 'cvs diff' to diff your local changes
> against the CVS tree. That would probably be easier than keeping two
> copies of the sources. (unless you don't have much bandwidth for the
> compare...)
>
Oh plenty of bandwidth, just new to the procedures, I'll give that a go
today.

> > screen_set #id [-]backlight <on|off|toggle|flash|blink>
>
> Isn't there already a backlight command, that affects the global
> backlight state?
Yep, it's still there though..in client_functions.c IIRC.

> In looking at your patch, it looks like you've
> replaced the global backlight state with a per screen backlight state.
Not replaced as such, the other code is still there, but in the current
implementation of my patch effectively renders it pointless.

> I like the addition of a per-screen backlight state so that the server
> can make sure to set the backlight to the appropriate state for a given
> screen automatically, but it looks like you've disabled the global
> backlight state. Have I missed something? If not, what do you think
> about having a "default" per-screen backlight state that says "no
> preference" and in that case, the server uses the current global
> backlight state. Also, if the server is started with the backlight in
> the "locked" state, then that should override the per-screen backlight
> settings just like it does the "backlight" protocol command.
>
That would be fairly simple to do, off the top of my head we have two
options on how to approach this.
a) I could initialize the s->backlight field based on the global
variable. If the program was started with backlight on then the screens
would start out with their backlight state set accordingly. Then it's
entirely up to the client to set the state to whatever they wish on a
per screen basis.

b) We could have a new state, BACKLIGHT_NOTSET. The s->backlight
variable would be initialized as this, if it wasn't set with the
screen_set function then it would inherit the global value at
draw_screen. Would need to modify the switch statement, perhaps setting
a local variable,

if (s->backlightstate == BACKLIGHT_NOTSET)
switchvar=global_backlightstate
else
switchvar=s->backlightstate,
switch (switchvar) { ...

> Does that make sense?
>
Does to me, how do those options sound to you.

> On the subject of timeouts, what about specifying the timeout in screen
> ticks. Most (all?) other time values in LCDproc are counted in ticks
> (1/8th of a second) The timeout should be as well. This would mean it
> could be an int. (Even though that really won't make any size difference
> in most cases, it would be consistent with other parameters.)
> Does that seem reasonable?
>
Not so sure about this one. It doesn't really make sense to have a
screen viable for one TIME_UNIT. Screens are a visual medium, this would
seem pointless. I should point out, in case it wasn't obvious from the
patch, that the s->timeout value is in ticks, it's converted from
seconds to TIME_UNITS

s->timeout = number * (TIME_UNIT * 8); // TIME_UNIT is 1/8th of a second

> > 2) In main.c after the timeout we check the timeout value of the screen,
> > it's it's expired the screen is removed.
> >
> > 3) I added two new startup parameters to allow you to choose the address
> > and port to listen on. Very important for security, can limit to
> > localhost etc.
>
> Very cool. Good idea.
>
Thanks go to Paul Kelly here in work for that.

> Just feedback. Overall, a good patch. I'll hold on to it until I hear
> from you.
>
And appreciated.

> Good job!
> :v)
>
Hurray for me :-)

Glen



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT lists.omnipotent.net




Archive powered by MHonArc 2.6.18.

Top of page