LCDproc development and user support list

Text archives Help


[lcdproc] My patchs at last


Chronological Thread 
  • From: ppokorny AT penguincomputing.com (Philip Pokorny)
  • Subject: [lcdproc] My patchs at last
  • Date: Mon, 18 Jun 2001 13:30:21 -0700

Glen Gray wrote:
>
> 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

Sorry Glen, I got busy with some things at work and wasn't able to
continue our discussion about your proposal.

I started looking at the backlight support that is already included in
the server. There is a BACKLIGHT_VIS mode that is "partially?"
implemented that the comments suggest would be a "client controlled"
backlight setting.

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

Does pointless mean dead? If the code is there but isn't doing
anything, we ought to clean that up. There is already an awful lot of
commented out and otherwise dead code in LCDproc already...

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

I think I like your second example better. It also brings into clearer
focus the question of which options take precedence? I think the
backlight state can be controlled from several different sources now:

1. LCDd command line (-backlight command line option to force the
backlight state)
2. Clients. (The lcdproc client calls "backlight (on|off|blink)" in
response to CPU LOAD)
3. Screens. (Your proposal)

Right now, the command line takes precendence over clients. (If you say
"LCDd -backlight on", then "backlight off" doesn't work.) How do we
extend this, given that backlight was formally a global variable
settable by all clients.

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

I'm not so sure... When I say ticks, I mean that the "time" values are
specified as integer counts of 1/8ths of a second (roughly...). The
line above would scale "number" as seconds to a timeout in TIME_UNIT
values (which happen to be microseconds... You then decrement timout by
TIME_UNIT each tick.

s->timeout -= TIME_UNIT ;

I'm suggesting:

s->timeout = number ;

and

--(s->timeout) ;


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

--
Philip Pokorny, Senior Engineer
http://www.penguincomputing.com

Penguin Computing - The World's Most Reliable Linux Systems


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