weston_log() seems to be the standard elsewhere in the codebase for
errors. These are the only two instances where perror() is used
instead, and their error messages aren't that informative anyway.
Signed-off-by: Bryce Harrington
---
src/compositor-wayland.c |4 ++--
1 file changed, 2 inser
On Wed, Mar 19, 2014 at 09:19:03AM +0200, Pekka Paalanen wrote:
> On Wed, 19 Mar 2014 00:21:20 +0100
> Hardening wrote:
>
> > Le 18/03/2014 20:34, Bryce W. Harrington a écrit :
> > > weston_log() seems to be the standard elsewhere in the codebase for
> > > errors. These are the only two instance
On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote:
> So you're saying that every time we're suspended, we simply throw out the
> entire context and drop all the devices on the floor, as if you just
> unplugged all of them?
fwiw, this is effectively what happens internally anyway, y
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
I suppose I just never thought of that. On first though, I don't see
anything wrong with that.
If that's what we should do, should
No functional changes
Signed-off-by: Peter Hutterer
---
I needed this for the rescan patch but it makes the calls more symmetrical,
so we might as well push it independently.
src/udev-seat.c | 41 +++--
1 file changed, 23 insertions(+), 18 deletions(-)
diff
Signed-off-by: Peter Hutterer
---
src/libinput.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/libinput.h b/src/libinput.h
index d6bf9f8..3e09871 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -691,6 +691,12 @@ struct libinput_interface {
* the given seat ID. New devices or
Previous return value was the straight ioctl, we should try to avoid errno
mangling.
This changes the API, if not the ABI. Callers with code along the lines of
if (libinput_device_get_keys() == -1) will now break.
Signed-off-by: Peter Hutterer
---
weston is not affected by this, it checks for <
This patch removes the extra modes parameter for the RDP compositor. And
make it support any mode that is requested (be aware that RDP client may not
support all possible modes, especially odd resolution).
This new version fixes remarks done by Jason Ekstrand. It also fixes
some missing spaces bet
Hardening,
By and large, I think it looks good. I have a few nit-picking comments
below that should take ~20 seconds to address.
I was trying to test it on my machine and nothing seems to resize. Is this
because the xfreerdp client doesn't support resizing or is it from some
other reason?
Thank
On Thu, Mar 20, 2014 at 8:04 AM, Pekka Paalanen wrote:
> On Thu, 20 Mar 2014 07:22:33 -0500
> Jason Ekstrand wrote:
>
> > Hi Pekka,
> > I've been meaning to get around to this one. Sorry it took me so long.
>
> Hi Jason,
>
> no worries.
>
> > On Mar 20, 2014 2:46 AM, "Pekka Paalanen" <
> pekka.
Pekka Paalanen wrote:
The sampling really goes into hair-splitting. It depends on how you
interpret a texel image; is each pixel a solid-colored tile, or does
the color vary smoothly from texel to the next. Then you have the
source rectangle, which is divided into dst_width x dst_height pixels
(
Pekka, Jason,
Jason Ekstrand wrote on 2014-03-20:
>
> On Mar 20, 2014 9:59 AM, "Pekka Paalanen"
> wrote:
>>
>> On Thu, 20 Mar 2014 13:31:31 +
>> "Konopelko, Pavel (P.)" wrote:
>>
>>> Hello everybody,
>>>
>>> Question: Given that somebody has Wayland/Weston 1.3 already
>>> integrated in t
On Mar 20, 2014 9:59 AM, "Pekka Paalanen" wrote:
>
> On Thu, 20 Mar 2014 13:31:31 +
> "Konopelko, Pavel (P.)" wrote:
>
> > Hello everybody,
> >
> > Question:
> > Given that somebody has Wayland/Weston 1.3 already integrated in
> > their system, what would it take to upgrade to the upcoming
>
On Thu, 20 Mar 2014 13:31:31 +
"Konopelko, Pavel (P.)" wrote:
> Hello everybody,
>
> Question:
> Given that somebody has Wayland/Weston 1.3 already integrated in
> their system, what would it take to upgrade to the upcoming
> Wayland/Weston 1.5? Is this just a matter of re-building it and
>
Hello everybody,
Question:
Given that somebody has Wayland/Weston 1.3 already integrated in their system,
what would it take to upgrade to the upcoming Wayland/Weston 1.5? Is this just
a matter of re-building it and everything will continue working out of the box?
Are there any adjustments in
On Thu, 20 Mar 2014 07:22:33 -0500
Jason Ekstrand wrote:
> Hi Pekka,
> I've been meaning to get around to this one. Sorry it took me so long.
Hi Jason,
no worries.
> On Mar 20, 2014 2:46 AM, "Pekka Paalanen"
> wrote:
> >
> > On Fri, 14 Mar 2014 14:38:10 +0200
> > Pekka Paalanen wrote:
> >
>
Hi Pekka,
I've been meaning to get around to this one. Sorry it took me so long.
On Mar 20, 2014 2:46 AM, "Pekka Paalanen"
wrote:
>
> On Fri, 14 Mar 2014 14:38:10 +0200
> Pekka Paalanen wrote:
>
> > From: Pekka Paalanen
> >
> > Hi,
> >
> > this series replaces the first 5 patches from
> >
http:
On Fri, 14 Mar 2014 14:38:10 +0200
Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Hi,
>
> this series replaces the first 5 patches from
> http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html
>
> Compared to the old series, this series carries the same 5 patches
> rebas
This is launched from hmi-controller by using hmi_client_start and create a
pthread.
The basic flow is as followed,
1/ create pthread
2/ read configuration from weston.ini.
3/ draw png file to surface according to configuration of weston.ini
4/ set up UI by using ivi-hmi-controller protocol
5/ Ent
19 matches
Mail list logo
