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/
On Fri, 14 Mar 2014 14:38:10 +0200
Pekka Paalanen ppaala...@gmail.com wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
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
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 pekka.paala...@collabora.co.uk
wrote:
On Fri, 14 Mar 2014 14:38:10 +0200
Pekka Paalanen ppaala...@gmail.com wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
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
On Thu, 20 Mar 2014 13:31:31 +
Konopelko, Pavel (P.) pkono...@visteon.com 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
On Mar 20, 2014 9:59 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 20 Mar 2014 13:31:31 +
Konopelko, Pavel (P.) pkono...@visteon.com wrote:
Hello everybody,
Question:
Given that somebody has Wayland/Weston 1.3 already integrated in
their system, what would it take to
Pekka, Jason,
Jason Ekstrand wrote on 2014-03-20:
On Mar 20, 2014 9:59 AM, Pekka Paalanen ppaala...@gmail.com
wrote:
On Thu, 20 Mar 2014 13:31:31 +
Konopelko, Pavel (P.) pkono...@visteon.com wrote:
Hello everybody,
Question: Given that somebody has Wayland/Weston 1.3 already
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
On Thu, Mar 20, 2014 at 8:04 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 20 Mar 2014 07:22:33 -0500
Jason Ekstrand ja...@jlekstrand.net 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,
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?
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
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
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
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 peter.hutte...@who-t.net
---
weston is not affected
No functional changes
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
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
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
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, you
On Wed, Mar 19, 2014 at 09:19:03AM +0200, Pekka Paalanen wrote:
On Wed, 19 Mar 2014 00:21:20 +0100
Hardening rdp.eff...@gmail.com 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
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 b.harring...@samsung.com
---
src/compositor-wayland.c |4 ++--
18 matches
Mail list logo