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: 18 Jun 2001 11:04:54 +0100

With all the talk of the API changes I realised that nobody responded to
this response of mine.

Whats the deal, do I make any changes, are the patchs to be included as
is ?

In the mood for over working and hacking late :-)
Glen

On 11 Jun 2001 09:57:58 +0100, Glen Gray wrote:
> 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
>




-----------------------------------------------------------
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