2014-04-23 19:40 に Pekka Paalanen さんは書きました:
Hi,
it's been a long while since I have looked at this, but I got a bit of
time to come back. I hope you haven't abandoned this effort yet. :-)
I looked at the PDF from your post on March 6th, 2014, and some of my
own comments I gave at that time to r
To provide a generic naming system of type_direction. That will become more
important once we add new axes as part of the ongoing work to support graphics
tablets.
Signed-off-by: Peter Hutterer
---
src/libinput.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/
On Mon, Apr 21, 2014 at 07:11:26PM +0200, Carlos Garnacho wrote:
> Those have been made mutually exclusive, to make sure only one or the
> other is notified when there is some uncertainty from the device.
>
> Signed-off-by: Carlos Garnacho
> ---
> src/evdev-tablet.c | 29
On Mon, Apr 21, 2014 at 07:11:25PM +0200, Carlos Garnacho wrote:
> Those are normalized to be in the [-1..1] range.
>
> Signed-off-by: Carlos Garnacho
> ---
> src/evdev-tablet.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-ta
On Mon, Apr 21, 2014 at 07:11:27PM +0200, Carlos Garnacho wrote:
> no vfuncs are used, only input_event arrays.
>
> Signed-off-by: Carlos Garnacho
> ---
> test/litest-int.h | 8 +
> test/litest.c | 90
> +++
> test/litest.h | 14 +
On Mon, Apr 21, 2014 at 07:11:18PM +0200, Carlos Garnacho wrote:
> This event would be emitted whenever a device with
> LIBINPUT_DEVICE_CAP_STYLUS capabilities changes its tool type.
>
> When the tablet reaches proximity, the tool/serial will be
> updated to match the current physical stylus'. Lik
On Mon, Apr 21, 2014 at 07:11:24PM +0200, Carlos Garnacho wrote:
> An axis_frame event is sent too to notify a set of simultaneous axis
> changes. Only the infrastructure is added, No axes are managed at the
> moment.
>
> Signed-off-by: Carlos Garnacho
> ---
> src/evdev-tablet.c | 107
> +++
On Mon, Apr 21, 2014 at 07:11:23PM +0200, Carlos Garnacho wrote:
> This works for stylus tap and primary/secondary button, and pad
> buttons.
>
> Signed-off-by: Carlos Garnacho
> ---
> src/evdev-tablet.c | 104
> +
> src/evdev-tablet.h | 3 +
On Mon, Apr 21, 2014 at 07:11:16PM +0200, Carlos Garnacho wrote:
> distance/pressure/xtilt/ytilt are handled at the moment, this leaves
> wheels/strips out at the moment...
>
> Signed-off-by: Carlos Garnacho
> ---
> src/libinput.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>
On Mon, Apr 21, 2014 at 07:11:15PM +0200, Carlos Garnacho wrote:
> This is so LIBINPUT_EVENT_POINTER_AXIS_FRAME events remaining from
> previous tests are discarded.
please instead update the tests so we pull the frame event off before we test
the next series. it safeguards us against accidental b
On Mon, Apr 21, 2014 at 07:11:14PM +0200, Carlos Garnacho wrote:
> This information has no coordinates itself, so only print out the event
> time.
please squash this in with the patch that introduces it (01/24). Same
applies for the other ones that just introduce new bits to print.
Cheers,
Pet
On Mon, Apr 21, 2014 at 07:11:11PM +0200, Carlos Garnacho wrote:
> It will be unlikely in this case to get both REL_WHEEL and REL_HWHEEL
> on a single EV_SYN, but for completeness.
>
> Signed-off-by: Carlos Garnacho
> ---
> src/evdev.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --gi
On Mon, Apr 21, 2014 at 07:11:10PM +0200, Carlos Garnacho wrote:
> This event marks the end of 1..N simultaneous axis changes. Will be
> useful to have users compress vscroll/hscroll processing in a single
> point, and will prove even more useful on devices with a higher number
> of axes, like tabl
Hey,
On Mon, Apr 21, 2014 at 07:11:09PM +0200, Carlos Garnacho wrote:
> Hey there!,
>
> Here's a few patches to have libinput handle events from tablets,
> these devices are basically pointer devices, with a varying range
> of extra buttons (either stylus or "pad" buttons), and extra ABS_*
> axes
On Sun, 27 Apr 2014 18:25:45 +0300
Pekka Paalanen
wrote:
> Sorry?
> ...
> Huh?
See below for an example and link to a demonstrator
> For FBO, you can create the storage with e.g. glTexImage2D, or some
> of the renderbuffer functions.
Storage is one thing. Being able to actually use it the oth
On Sun, 27 Apr 2014 18:13:04 +0300
Pekka Paalanen
wrote:
> Do they, really? Or does it happen on-demand, slowly RAM<->VRAM,
> causing hickups, a bit like traditional swapping RAM to disk?
The OpenGL specification doesn't define it. Drivers can implement it as
they want to.
> Especially when re-
On Sun, 27 Apr 2014 11:35:37 +0200
Wolfgang Draxinger wrote:
> On Sun, 27 Apr 2014 11:30:18 +0300
> Pekka Paalanen
> wrote:
>
>
> > > I'm still trying to get an GBM configuration working that
> > > targets an off-screen buffer so that OpenGL operations are
> > > carried out toward it on the GP
On Sun, 27 Apr 2014 14:45:44 +0200
Wolfgang Draxinger wrote:
> On Sun, 27 Apr 2014 13:57:45 +0200
> John Kåre Alsaker
> wrote:
>
> > We still are limited by both graphics memory and bandwidth.
> > A fullscreen 64bpp 4K client will use about 128 MB for the
> > framebuffer.
>
> Indeed. OTOH clie
On Sun, 27 Apr 2014 13:57:45 +0200
John Kåre Alsaker
wrote:
> Since VGA is a ting of the past, I'm more interested in what the
> display do.
Display devices always were nonlinear in their signal response. That's
why gamma LUTs got introduced in the first place, to deal with the
saturation effect
On Sun, Apr 27, 2014 at 12:30 PM, Wolfgang Draxinger
wrote:
> On Sun, 27 Apr 2014 12:11:39 +0200
> John Kåre Alsaker
> wrote:
>
>> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
>> My patch has bit-rotted a bit now, but it gives you an idea about
>> what to do:
>> https://git
On Sun, 27 Apr 2014 12:11:39 +0200
John Kåre Alsaker
wrote:
> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
> My patch has bit-rotted a bit now, but it gives you an idea about
> what to do:
> https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
>
> M
I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
My patch has bit-rotted a bit now, but it gives you an idea about what to do:
https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
My motivation for this was to have clients render with linear gamma.
One t
On Sun, 27 Apr 2014 11:35:37 +0200
Wolfgang Draxinger
wrote:
> > Btw. weren't FBConfigs a GLX thing?
>
> No, XRender actually; GLX just piggybacks on that.
Okay, that needs some explanation. While all functions that have
"FBConfig" in their name are part of GLX you actually have so use some
XRe
On Sun, 27 Apr 2014 11:30:18 +0300
Pekka Paalanen
wrote:
> > I'm still trying to get an GBM configuration working that targets
> > an off-screen buffer so that OpenGL operations are carried out
> > toward it on the GPU but without attaching it to a CRTC.
>
> I think you should do that with an F
On Sun, 27 Apr 2014 00:03:19 +0200
Wolfgang Draxinger wrote:
> On Sat, 26 Apr 2014 17:10:38 -0400
> "Jasper St. Pierre" wrote:
>
> > Outside of an X11 environment, the only standard is EGL, with a
> > Wayland backend for Wayland apps, or a GBM backend for native
> > modesetting.
>
> Well, GBM
25 matches
Mail list logo
