On 25/02/12 01:04 , Kristian Høgsberg wrote:
On Fri, Feb 24, 2012 at 2:42 AM, Peter Hutterer
wrote:
On Thu, Feb 23, 2012 at 04:26:23PM -0500, Kristian Hoegsberg wrote:
On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
Includes rudimentary styling only.
Signed-off-by: Peter Hut
On 02/24/2012 09:02 PM, Bill Spitzak wrote:
Tiago Vignatti wrote:
DISPLAY_ON → DISPLAY_DIM → DISPLAY_SCREENSAVER → DISPLAY_OFF
Won't there be some interest in making the backlight dim *after* the
screensaver starts?
hum, I don't see a real usage for such. I don't think we have to be that
fl
On Fri, 24 Feb 2012 14:34:52 -0500
Kristian Høgsberg wrote:
> On Fri, Feb 24, 2012 at 1:53 PM, Jesse Barnes
> wrote:
> > On Thu, 16 Feb 2012 15:54:41 +0200
> > Tiago Vignatti wrote:
> >
> >> On 02/16/2012 03:46 PM, Michael Hasselmann wrote:
> >> > On Thu, 2012-02-16 at 15:40 +0200, Tiago Vigna
On Fri, Feb 24, 2012 at 1:53 PM, Jesse Barnes wrote:
> On Thu, 16 Feb 2012 15:54:41 +0200
> Tiago Vignatti wrote:
>
>> On 02/16/2012 03:46 PM, Michael Hasselmann wrote:
>> > On Thu, 2012-02-16 at 15:40 +0200, Tiago Vignatti wrote:
>> >> On 02/16/2012 01:42 PM, Michael Hasselmann wrote:
>> >>> Hi,
Tiago Vignatti wrote:
DISPLAY_ON → DISPLAY_DIM → DISPLAY_SCREENSAVER → DISPLAY_OFF
Won't there be some interest in making the backlight dim *after* the
screensaver starts? I can imagine the control ui being a bunch of timing
sliders, which the user can move anywhere. Thus the screen saver can
On Thu, 16 Feb 2012 15:54:41 +0200
Tiago Vignatti wrote:
> On 02/16/2012 03:46 PM, Michael Hasselmann wrote:
> > On Thu, 2012-02-16 at 15:40 +0200, Tiago Vignatti wrote:
> >> On 02/16/2012 01:42 PM, Michael Hasselmann wrote:
> >>> Hi,
> >>>
> >>> just noticed these small issues while going throug
On Fri, 24 Feb 2012 18:08:40 +0200
Tiago Vignatti wrote:
> The code being removed is actually never triggered due a race
> with the client that has just launched. However the client will
> issue an surface_attach to the compositor that will run the same
> routines inside map() later a bit.
Did y
On Fri, Feb 24, 2012 at 11:08 AM, Tiago Vignatti
wrote:
> Hi,
>
> Following is the kinda of cleanup I found worth before actually implement the
> drm routines for backlight control and DPMS. Please comment on!
Hi Tiago,
We are looking to add dpms and backlight support to weston, so let's
do that
DISPLAY_ON → DISPLAY_DIM → DISPLAY_SCREENSAVER → DISPLAY_OFF
transitions between states happen in this same sequential way and it's based
on time of user idleness. Once some (input) activity is generated, then it
jumps back to the first state.
We're still using one single timer for this implement
Signed-off-by: Tiago Vignatti
---
src/shell.c |6 +++---
weston-desktop-shell.ini |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index 270f789..0029a1e 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -148,13 +148,13 @@ shell_conf
just like "duration"
Signed-off-by: Tiago Vignatti
---
src/compositor.c | 31 +--
src/shell.c | 18 ++
weston-desktop-shell.ini |1 +
3 files changed, 20 insertions(+), 30 deletions(-)
diff --git a/src/compositor.c b/src/c
Currently we have only two states for the timer ("idle" and "duration"), so
the changes introduced will be effectively useful when more states are in
place (for display control).
Anyways, we have now an easy API and internal fields are accessed only via
functions.
Signed-off-by: Tiago Vignatti
-
Only input events generate activity to wake up and unlock the compositor -
that's the theory at least for now, and this doesn't require any backend
knowledge. Note that the act of hotplug the device itself won't awake the
compositor, but the _activity_ of the new device will -- we're okay.
So make
The code being removed is actually never triggered due a race with the client
that has just launched. However the client will issue an surface_attach to
the compositor that will run the same routines inside map() later a bit.
Signed-off-by: Tiago Vignatti
---
src/shell.c | 10 --
1 fil
Signed-off-by: Tiago Vignatti
---
clients/.gitignore |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/clients/.gitignore b/clients/.gitignore
index 5954a54..9bbb1ab 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -17,7 +17,7 @@ simple-touch
smoke
tablet-shel
Hi,
Following is the kinda of cleanup I found worth before actually implement the
drm routines for backlight control and DPMS. Please comment on!
Thanks,
Tiago Vignatti (7):
gitignore: update it
shell: remove unused code from screensaver
compositor: activity happens in core scope only
c
On Fri, Feb 24, 2012 at 12:28 AM, Scott Moreau wrote:
> This effectively eats the keybinding events, as we don't want them sent to
> clients.
That looks much better. But shouldn't we feed the initial up/down key
to the zoom_key handler? It looks like we just throw that away now.
Kristian
> -
On Fri, Feb 24, 2012 at 2:42 AM, Peter Hutterer
wrote:
> On Thu, Feb 23, 2012 at 04:26:23PM -0500, Kristian Hoegsberg wrote:
>> On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote:
>> > Includes rudimentary styling only.
>> >
>> > Signed-off-by: Peter Hutterer
>> > ---
>> > A few thing
On 24/02/12 20:15 , Michael Hasselmann wrote:
On Fri, 2012-02-24 at 17:42 +1000, Peter Hutterer wrote:
I've played around a bit today and the result is this:
http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/
The blue text for type names etc. is a bit confusing, in the sense that
they
On Fri, 2012-02-24 at 17:42 +1000, Peter Hutterer wrote:
> I've played around a bit today and the result is this:
> http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/
The blue text for type names etc. is a bit confusing, in the sense that
they are not links.
regards,
Michael
___
20 matches
Mail list logo
