date:20170515

Re: xf86 input driver API question

2017-05-15 Thread Peter Hutterer

On Mon, May 15, 2017 at 08:25:07AM +0200, Martin Kepplinger wrote:
> Am 2017-05-15 um 06:02 schrieb Alan Coopersmith:
> > On 05/14/17 08:48 AM, Martin Kepplinger wrote:
> >> might be a dumb question, but I don't find resources: If an Xorg input
> >> driver supports GET_ABI_MAJOR() < 14, what exactly does that mean?
> >> xserver < 1.14 is supported? Where is the documentation on this driver
> >> ABI?
> > 
> > It's out of date, but https://www.x.org/wiki/XorgModuleABIVersions/ has a
> > table mapping the various ABI versions to Xorg server versions.
> > 
> > The ABI documentation is mostly in the headers and sources for the X
> > server.
> > 
> 
> Please update that :) Furthermore. I'd need a list of API symbols and
> functions with the server version they got introduced.

the server's API isn't like a library one, it's mostly a successino of 'we
need that symbol' or a 'that one needs to change'. So there's no real list
of API symbols, though sdksyms.sh will produce something resembling it. That
won't tell you the details on the ABI though (it won't pick up on parameter
changes).

yes, we know that is terrible, such is life. if we had a time machine, it'd
be different. (Then again, if we really had a time machine, fixing the
xserver driver ABI mess likely wouldn't be much of a priority) 

> Specifically, since when exist:
> 
> xf86IDrvMsg()
> xf86PostTouchEvent()

iirc that one was introduced in 1.12

> but also the property labels.

I'm not sure what you mean by property labels, but button and axis labels
were added in 1.7 with XI2.0 support (iirc).

> https://www.x.org/wiki/Development/Documentation/Multitouch/ says 2.2,
> does that mean, xserver minimum version 1.6?

2.2 refers to the inputproto version.

Cheers,
   Peter

> It'd make development very much easier if there'd be just one
> documentation page with this kept up to date. It really could be clearer.
> 
> thanks for getting back at me!
> 
>  martin
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL] Mainly hw/xwin warning fixes

2017-05-15 Thread Adam Jackson

On Fri, 2017-05-12 at 19:22 +0100, Jon Turney wrote:
> The following changes since commit 49c742557457ff9200a10f32daadfcea50d4911c:
> 
>   meson: Fix CLOCK_MONOTONIC test (2017-05-12 09:49:33 -0400)
> 
> are available in the git repository at:
> 
>   git://people.freedesktop.org/~jturney/xserver 
> 
> for you to fetch changes up to 1520c6ad6783178a4d4538b7c549c7948e419af0:
> 
>   hw/xwin: Fix -Wunused-function warning for MessageName() in non-debug 
> builds (2017-05-12 19:17:22 +0100)

Merged, thanks!

remote: I: patch #150946 updated using rev 
7a90c9b24e6776c8f1fa43df4268f79a465c0d4e.
remote: I: patch #151284 updated using rev 
319daa7a9fa8bcfdefb08d7770912775af22ad99.
remote: I: patch #150948 updated using rev 
e49f5947eda578d8b029f42fb4ec9c90f413b4b3.
remote: I: patch #150949 updated using rev 
fd96ff7fb325f54cb06c2bf5b8c37c75457b5c42.
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   7a19a3e09..fd96ff7fb  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Sergey Udaltsov

Hi Hans

I can push, of course, if the mutual consensus is that now is the right
time for it.

Cheers

Sergey

On Mon, May 15, 2017 at 8:26 AM, Hans de Goede  wrote:

> Hi,
>
> On 15-05-17 03:06, Peter Hutterer wrote:
>
>> adding svu to CC:
>>
>> On Fri, May 12, 2017 at 04:18:42PM +0200, Hans de Goede wrote:
>>
>>> KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
>>> current xproto master defines keysyms for these. Add mappings for
>>> these keys.
>>>
>>> The XF86UWB keysm exists for quite a while now, as does the KEY_SOUND
>>> evdev code for it, so lets adds a mapping for that too.
>>>
>>> Note that this replaces the I255 to XF86Hibernate mapping in
>>> xkb_symbols "evdev", I don't know where that came from, but it is
>>> wrong, I255 was until now not defined in keycodes/evdev and
>>> KEY_HIBERNATE is not defined in linux/input-event-codes.h .
>>>
>>
>> see xk-c commit 7b3bfb3ec4b, has a link to the thread. After a bit of
>> digging, this got merged into dmitry's next tree (see
>> https://patchwork.kernel.org/patch/9742/) but never ended up in master.
>> My email archives trail out from there and I'm not sure what exactly
>> happens, google isn't forthcoming either.
>>
>> Looks like we simply pushed the xk-c patch too early, assumign that -next
>> will end up in master. But anyway, we've survived 8 years without it, so I
>> think we're good :)
>>
>
> Thank you for the digging I've updated the commit message to reflect
> this info and correct the grammar errors Bastien pointed out. I've
> tried to push this, but it just hangs ? Maybe because I don't have
> write access to xkeyboard-config (it is sitting outside of the
> xorg tree after all) ?
>
> Anyways I'll send a v2 with the improved commit message, if you can push
> that, that would be great.
>
> Regards,
>
> Hans
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xf86 input driver API question

2017-05-15 Thread Martin Kepplinger

Am 2017-05-15 um 06:02 schrieb Alan Coopersmith:
> On 05/14/17 08:48 AM, Martin Kepplinger wrote:
>> might be a dumb question, but I don't find resources: If an Xorg input
>> driver supports GET_ABI_MAJOR() < 14, what exactly does that mean?
>> xserver < 1.14 is supported? Where is the documentation on this driver
>> ABI?
> 
> It's out of date, but https://www.x.org/wiki/XorgModuleABIVersions/ has a
> table mapping the various ABI versions to Xorg server versions.
> 
> The ABI documentation is mostly in the headers and sources for the X
> server.
> 

Please update that :) Furthermore. I'd need a list of API symbols and
functions with the server version they got introduced.

Specifically, since when exist:

xf86IDrvMsg()
xf86PostTouchEvent()
but also the property labels.

https://www.x.org/wiki/Development/Documentation/Multitouch/ says 2.2,
does that mean, xserver minimum version 1.6?

It'd make development very much easier if there'd be just one
documentation page with this kept up to date. It really could be clearer.

thanks for getting back at me!

 martin

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Bastien Nocera

Hey,

Comments inline.

On Mon, 2017-05-15 at 08:36 +0200, Hans de Goede wrote:
> KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
> current xproto master defines keysyms for these. Add mappings for
> these keys.
> 
> The XF86UWB keysm exists for quite a while now, as does the KEY_SOUND

"keysym has existed"

> evdev code for it, so lets adds a mapping for that too.

"let's add"

> Note that this replaces the I255 to XF86Hibernate mapping in
> xkb_symbols "evdev", I don't know where that came from, but it is
> wrong, I255 was until now not defined in keycodes/evdev and
> KEY_HIBERNATE is not defined in linux/input-event-codes.h .
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100970
> Cc: Bastien Nocera 
> Cc: Benjamin Berg 
> Signed-off-by: Hans de Goede 
> Reviewed-by: Peter Hutterer 
> ---
>  keycodes/evdev | 2 ++
>  symbols/inet   | 7 ---
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/keycodes/evdev b/keycodes/evdev
> index 624ac68..51a6e26 100644
> --- a/keycodes/evdev
> +++ b/keycodes/evdev
> @@ -281,6 +281,8 @@ default xkb_keycodes "evdev" {
>    = 251;   // #define KEY_BRIGHTNESS_CYCLE243
>    = 252;   // #define KEY_BRIGHTNESS_ZERO 244
>    = 253;   // #define KEY_DISPLAY_OFF 245
> +  = 254;   // #define KEY_WWAN246
> +  = 255;   // #define KEY_RFKILL  247
>  
>   // Fake keycodes for virtual keys
>    =   92;
> diff --git a/symbols/inet b/symbols/inet
> index 5403e77..1e06aa9 100644
> --- a/symbols/inet
> +++ b/symbols/inet
> @@ -184,7 +184,7 @@ xkb_symbols "evdev" {
>  key    {  [ Print ]   };
>  //  key    {  [ ]   }; // KEY_HP
>  key    {  [ XF86WebCam]   };
> -//  key    {  [ ]   }; // KEY_SOUND
> +key    {  [ XF86AudioPreset   ]   };

This is an existing keysym, but what does it correspond to?

>  //  key    {  [ ]   }; // KEY_QUESTION
>  key    {  [ XF86Mail  ]   };
>  key    {  [ XF86Messenger ]   }; //
> KEY_CHAT
> @@ -210,13 +210,14 @@ xkb_symbols "evdev" {
>  key    {  [ XF86Battery   ]   };
>  key    {  [ XF86Bluetooth ]   };
>  key    {  [ XF86WLAN  ]   };
> +key    {  [ XF86UWB   ]   };

Feels weird using up a slot for a key that toggles an obsolete wireless
protocol...

>  //  key    {  [ ]   }; // KEY_VIDEO_NEXT  --  drive
> next video source
>  //  key    {  [ ]   }; // KEY_VIDEO_PREV  --  drive
> previous video source
>  //  key    {  [ ]   }; // KEY_BRIGHTNESS_CYCLE  
> --  bright up, max++ == min
>  //  key    {  [ ]   }; // KEY_BRIGHTNESS_ZERO  
> --  brightness off
>  //  key    {  [ ]   }; // KEY_DISPLAY_OFF  --  turn
> off display
> -//  key    {  [ ]   }; // KEY_WIMAX
> -key    {  [ XF86Hibernate ]   }; //
> KEY_HIBERNATE
> +key    {  [ XF86WWAN  ]   }; //
> KEY_WWAN
> +key    {  [ XF86RFKill]   }; //
> KEY_RFKILL
>  
>  key    {  [ XF86Tools ]   };
>  key    {  [ XF86Launch5   ]   };

Cheers
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Bastien Nocera

On Mon, 2017-05-15 at 09:07 +0200, Hans de Goede wrote:
> > > -//  key    {  [ ]   }; // KEY_SOUND
> > > +    key    {  [ XF86AudioPreset   ]   };
> > 
> > This is an existing keysym, but what does it correspond to?
> 
>  From XF86keysym.h :
> 
> #define XF86XK_AudioPreset 0x1008FFB6 /* Select equalizer preset,
> e.g. theatre-mode */
> 
> I221 corresponds to KEY_SOUND which gets used in the kernel in
> the following ways:
> 
> drivers/platform/x86/peaq-wmi.c:
> Used for the Dolby button which under windows toggles through
> theater/game/speach/music mode.
> 
> drivers/media/rc/keymaps/rc-kworld-pc150u.c
> 73: { 0x48, KEY_SOUND}, /* switch theater mode */
> 
> drivers/media/rc/keymaps/rc-cec.c
> 67: { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
> 
> drivers/media/rc/keymaps/rc-encore-enltv.c
> 74: { 0x4d, KEY_SOUND },    /* DVD sound */

Looks like we won't need to handle *that* one in gnome-settings-daemon.

Thanks
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: x11perf putimagexy10 extremly slow for glamor on i965

2017-05-15 Thread Adam Jackson

On Sun, 2017-05-14 at 16:16 -0700, Keith Packard wrote:
> > Clemens Eisserer  writes:
> 
> > I have observed extremly low x11perf-putimagexy10 results when using
> > glamor on top of the i965 driver - while shmput10 results are quite
> > ok.
> 
> Why do you care? xy format images are not something you should be using
> at all; they were designed for 1980s era Apollo workstations.

Indeed. But for the morbidly curious...

Glamor mostly doesn't accelerate xy image handling because GL mostly
doesn't believe in planar bitmaps as, like, a thing. The fallback path
creates a pbo, copies out from the drawable's fbo to the pbo,
glMapBuffer's the pbo, runs the op against the pbo with fb, and then
copies the data back to the fbo. So that's bad enough, now every
operation is at least two more blits.

Underneath, fbPutXYImage works by walking the bit planes in order and
merging them into the destination. This is just about pathologically
bad, because it means a read/modify/write cycle of the entire
destination _for each plane_. So you're doing many more operations per
pixel, and you're fighting the cache to do it.

You're also not comparing apples to apples in your test. shmput10 is
10x10 ZPixmap, you mean to compare to shmputxy10. Interestingly at
least on my glamor machine shmputxy10 is _slower_ than non-shm:

 84000 trep @   0.1108 msec (  9030.0/sec): PutImage XY 10x10 square
 72000 trep @   0.1302 msec (  7680.0/sec): ShmPutImage XY 10x10 square

I think that's just a funny interaction with the MIT-SHM code, which
when faced with an xy image will blast it into a (presumably z image)
scratch pixmap first and then CopyArea from that to the destination. If
glamor creates that pixmap on the GPU we're still going to do the same
fallback logic for the xy putimage phase, and then yet another blit
from that to the real destination. Oops. Forcing that pixmap's usage to
be GLAMOR_CREATE_PIXMAP_CPU brings shmputxy10 to 117kops/sec, which is
quite a bit nicer; probably we should formalize that usage for
ShmPutImage, and maybe do the equivalent trick for wire PutImage too.

But compare this all with leaving your pixels in a sensible format:

600 trep @   0.0019 msec (525000.0/sec): PutImage 10x10 square
480 trep @   0.0022 msec (454000.0/sec): ShmPutImage 10x10 square

XY images are just losers, don't bother. (ShmPutImage being slower is
curious, and it's slower for larger request sizes too, so there's
definitely something amiss there we should dig into.)

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: speeding up distributed multihead (xdmx)

2017-05-15 Thread Adam Jackson

On Sat, 2017-05-13 at 22:27 -0400, Joshua Marshall wrote:

> This summer I've been charged with updating my university's display
> wall.  It looks like the software features of X11 eclipse those of
> DisplayCluster, but in speaking with the DisplayCluster author, it
> _actually works_.  In particular, the performance over 16 screens was
> wholly unacceptable and traced it to a part of the server which
> serializes a nondescript something.
> 
> Now, does anybody know what he is referring to, if the performance
> issues persist, and how hard it might be to fix them?

I looked up the DisplayCluster white paper, and while it does say that
dmx doesn't scale beyond 16 tiles that's perhaps an unwarranted
conclusion. I suspect what it refers to is that the stock X server
source has an internal limitation of 16 screens. So yeah, performance
beyond 16 tiles is going to be unacceptable, because it's zero ;)

That's literally just a #define controlling the size of a few arrays
though, you can change MAXSCREENS to whatever you want when you build.
Alternatively, subdivide: one Xdmx frontend talking to four Xdmx
middle-ends each talking to 16 tiles, for example.

There could certainly be performance problems beyond that; more details
would be helpful. Xdmx definitely has other limitations that might make
it unsuitable for your use (old OpenGL support, 32 kilopixel coordinate
limit, no compressed image transfer) so I don't want to oversell it,
but if you do encounter issues please let us know so we can determine
whether they're fixable.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede


Hi,

On 15-05-17 16:59, Sergey Udaltsov wrote:

Hi Hans

I can push, of course, if the mutual consensus is that now is the right time 
for it.


I consider the patch ready for merging / pushing, which is why I tried to push 
it
myself :)

Regards,

Hans


On Mon, May 15, 2017 at 8:26 AM, Hans de Goede > wrote:

Hi,

On 15-05-17 03:06, Peter Hutterer wrote:

adding svu to CC:

On Fri, May 12, 2017 at 04:18:42PM +0200, Hans de Goede wrote:

KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
current xproto master defines keysyms for these. Add mappings for
these keys.

The XF86UWB keysm exists for quite a while now, as does the 
KEY_SOUND
evdev code for it, so lets adds a mapping for that too.

Note that this replaces the I255 to XF86Hibernate mapping in
xkb_symbols "evdev", I don't know where that came from, but it is
wrong, I255 was until now not defined in keycodes/evdev and
KEY_HIBERNATE is not defined in linux/input-event-codes.h .


see xk-c commit 7b3bfb3ec4b, has a link to the thread. After a bit of
digging, this got merged into dmitry's next tree (see
https://patchwork.kernel.org/patch/9742/ 
) but never ended up in master.
My email archives trail out from there and I'm not sure what exactly
happens, google isn't forthcoming either.

Looks like we simply pushed the xk-c patch too early, assumign that 
-next
will end up in master. But anyway, we've survived 8 years without it, 
so I
think we're good :)


Thank you for the digging I've updated the commit message to reflect
this info and correct the grammar errors Bastien pointed out. I've
tried to push this, but it just hangs ? Maybe because I don't have
write access to xkeyboard-config (it is sitting outside of the
xorg tree after all) ?

Anyways I'll send a v2 with the improved commit message, if you can push
that, that would be great.

Regards,

Hans



___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Initial Haiku support

2017-05-15 Thread Emil Velikov

On 15 May 2017 at 12:06, Eric Engestrom  wrote:
> On Saturday, 2017-05-06 11:54:52 +, James Taylor wrote:
>> Hello Everyone,
>>
>> I'm mentoring Haiku's GSoC project for porting DRM to Haiku
>> (www.haiku-os.org). Since my student will be doing the bulk of the
>> work on the DRM kernel drivers proper, I decided to start looking at
>> some of the other packages that we'll have to port, the first being
>> libDRM. Seeing as libpciaccess is a dependency and it hasn't been
>> ported yet, I've gone ahead and prepared a patch that allows it to
>> build on Haiku. Please review and if possible merge. Seeing as I don't
>> really have a way to test it right now, there may be additional
>> patches in the future to tweak the library to work for us. Please feel
>> free to contact me with any questions or comments via email or on
>> Freenode, my nick is Duggan.
>>
>> Thank you.
>
> If you could send your next patches using `git send-email`, it would
> make it easier (and thus quicker) for people to review them :)
>
> I had a quick look, and it won't have any effect on non-haiku platforms,
> so it should be fine to land, whatever state the haiku bit is.
>
AFAICT the patch is a dummy cp ./src/{freebsd,haiku}_pci.c + sed
"s/freebsd/haiku/Ig" and is missing any integration. Both Makefile.am
and configure.ac.

Since there's no actual users of drm_intel_get_aperture_sizes's
mappable (the code that requires libpciaccess), just return a dummy
value and not bother with any of this ;-)

-Emil
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Initial Haiku support

2017-05-15 Thread Eric Engestrom

On Saturday, 2017-05-06 11:54:52 +, James Taylor wrote:
> Hello Everyone,
> 
> I'm mentoring Haiku's GSoC project for porting DRM to Haiku
> (www.haiku-os.org). Since my student will be doing the bulk of the
> work on the DRM kernel drivers proper, I decided to start looking at
> some of the other packages that we'll have to port, the first being
> libDRM. Seeing as libpciaccess is a dependency and it hasn't been
> ported yet, I've gone ahead and prepared a patch that allows it to
> build on Haiku. Please review and if possible merge. Seeing as I don't
> really have a way to test it right now, there may be additional
> patches in the future to tweak the library to work for us. Please feel
> free to contact me with any questions or comments via email or on
> Freenode, my nick is Duggan.
> 
> Thank you.

If you could send your next patches using `git send-email`, it would
make it easier (and thus quicker) for people to review them :)

I had a quick look, and it won't have any effect on non-haiku platforms,
so it should be fine to land, whatever state the haiku bit is.

Acked-by: Eric Engestrom 

You are missing the build-system bits to integrate your code, however.
Something like this?

8<
diff --git a/src/Makefile.am b/src/Makefile.am
index 3a46a85..96d9786 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -46,6 +46,10 @@ OS_SUPPORT = openbsd_pci.c
 # VGA Arbiter code is included in openbsd_pci.c
 endif
 
+if HAIKU
+OS_SUPPORT = haiku_pci.c
+endif
+
 if SOLARIS
 OS_SUPPORT = solx_devfs.c pci_tools.h
 VGA_ARBITER = common_vgaarb_stub.c
>8
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v2 xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede

KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
current xproto master defines keysyms for these. Add mappings for
these keys.

The XF86UWB keysm has existed for quite a while now, as has the KEY_UWB
evdev code for it, so let's adds a mapping for that too.

Note that this replaces the I255 to XF86Hibernate mapping in
xkb_symbols "evdev", At one point in time the kernel input next tree
had #define KEY_HIBERNATE 247 on which this mapping was based:
https://patchwork.kernel.org/patch/9742/
but that never got merged in to the mainline kernel.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100970
Cc: Bastien Nocera 
Cc: Benjamin Berg 
Signed-off-by: Hans de Goede 
Reviewed-by: Peter Hutterer 
---
Changes in v2:
-Improve commit message
---
 keycodes/evdev | 2 ++
 symbols/inet   | 7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/keycodes/evdev b/keycodes/evdev
index 624ac68..51a6e26 100644
--- a/keycodes/evdev
+++ b/keycodes/evdev
@@ -281,6 +281,8 @@ default xkb_keycodes "evdev" {
 = 251;   // #define KEY_BRIGHTNESS_CYCLE243
 = 252;   // #define KEY_BRIGHTNESS_ZERO 244
 = 253;   // #define KEY_DISPLAY_OFF 245
+= 254;   // #define KEY_WWAN246
+= 255;   // #define KEY_RFKILL  247
 
// Fake keycodes for virtual keys
 =   92;
diff --git a/symbols/inet b/symbols/inet
index 5403e77..1e06aa9 100644
--- a/symbols/inet
+++ b/symbols/inet
@@ -184,7 +184,7 @@ xkb_symbols "evdev" {
 key{  [ Print ]   };
 //  key{  [ ]   }; // KEY_HP
 key{  [ XF86WebCam]   };
-//  key{  [ ]   }; // KEY_SOUND
+key{  [ XF86AudioPreset   ]   };
 //  key{  [ ]   }; // KEY_QUESTION
 key{  [ XF86Mail  ]   };
 key{  [ XF86Messenger ]   }; // KEY_CHAT
@@ -210,13 +210,14 @@ xkb_symbols "evdev" {
 key{  [ XF86Battery   ]   };
 key{  [ XF86Bluetooth ]   };
 key{  [ XF86WLAN  ]   };
+key{  [ XF86UWB   ]   };
 //  key{  [ ]   }; // KEY_VIDEO_NEXT  --  drive next video 
source
 //  key{  [ ]   }; // KEY_VIDEO_PREV  --  drive previous 
video source
 //  key{  [ ]   }; // KEY_BRIGHTNESS_CYCLE  --  bright up, 
max++ == min
 //  key{  [ ]   }; // KEY_BRIGHTNESS_ZERO  --  brightness off
 //  key{  [ ]   }; // KEY_DISPLAY_OFF  --  turn off display
-//  key{  [ ]   }; // KEY_WIMAX
-key{  [ XF86Hibernate ]   }; // KEY_HIBERNATE
+key{  [ XF86WWAN  ]   }; // KEY_WWAN
+key{  [ XF86RFKill]   }; // KEY_RFKILL
 
 key{  [ XF86Tools ]   };
 key{  [ XF86Launch5   ]   };
-- 
2.12.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede


Hi,

On 15-05-17 03:06, Peter Hutterer wrote:

adding svu to CC:

On Fri, May 12, 2017 at 04:18:42PM +0200, Hans de Goede wrote:

KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
current xproto master defines keysyms for these. Add mappings for
these keys.

The XF86UWB keysm exists for quite a while now, as does the KEY_SOUND
evdev code for it, so lets adds a mapping for that too.

Note that this replaces the I255 to XF86Hibernate mapping in
xkb_symbols "evdev", I don't know where that came from, but it is
wrong, I255 was until now not defined in keycodes/evdev and
KEY_HIBERNATE is not defined in linux/input-event-codes.h .


see xk-c commit 7b3bfb3ec4b, has a link to the thread. After a bit of
digging, this got merged into dmitry's next tree (see
https://patchwork.kernel.org/patch/9742/) but never ended up in master.
My email archives trail out from there and I'm not sure what exactly
happens, google isn't forthcoming either.

Looks like we simply pushed the xk-c patch too early, assumign that -next
will end up in master. But anyway, we've survived 8 years without it, so I
think we're good :)


Thank you for the digging I've updated the commit message to reflect
this info and correct the grammar errors Bastien pointed out. I've
tried to push this, but it just hangs ? Maybe because I don't have
write access to xkeyboard-config (it is sitting outside of the
xorg tree after all) ?

Anyways I'll send a v2 with the improved commit message, if you can push
that, that would be great.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede


Hi,

On 15-05-17 08:50, Bastien Nocera wrote:

Hey,

Comments inline.

On Mon, 2017-05-15 at 08:36 +0200, Hans de Goede wrote:

KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
current xproto master defines keysyms for these. Add mappings for
these keys.

The XF86UWB keysm exists for quite a while now, as does the KEY_SOUND


"keysym has existed"


evdev code for it, so lets adds a mapping for that too.


"let's add"


Thank you both fixed.




Note that this replaces the I255 to XF86Hibernate mapping in
xkb_symbols "evdev", I don't know where that came from, but it is
wrong, I255 was until now not defined in keycodes/evdev and
KEY_HIBERNATE is not defined in linux/input-event-codes.h .

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100970
Cc: Bastien Nocera 
Cc: Benjamin Berg 
Signed-off-by: Hans de Goede 
Reviewed-by: Peter Hutterer 
---
  keycodes/evdev | 2 ++
  symbols/inet   | 7 ---
  2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/keycodes/evdev b/keycodes/evdev
index 624ac68..51a6e26 100644
--- a/keycodes/evdev
+++ b/keycodes/evdev
@@ -281,6 +281,8 @@ default xkb_keycodes "evdev" {
 = 251; // #define KEY_BRIGHTNESS_CYCLE243
 = 252; // #define KEY_BRIGHTNESS_ZERO 244
 = 253; // #define KEY_DISPLAY_OFF 245
+= 254; // #define KEY_WWAN246
+= 255; // #define KEY_RFKILL  247
  
  	// Fake keycodes for virtual keys

 =   92;
diff --git a/symbols/inet b/symbols/inet
index 5403e77..1e06aa9 100644
--- a/symbols/inet
+++ b/symbols/inet
@@ -184,7 +184,7 @@ xkb_symbols "evdev" {
  key{  [ Print ]   };
  //  key{  [ ]   }; // KEY_HP
  key{  [ XF86WebCam]   };
-//  key{  [ ]   }; // KEY_SOUND
+key{  [ XF86AudioPreset   ]   };


This is an existing keysym, but what does it correspond to?


From XF86keysym.h :

#define XF86XK_AudioPreset 0x1008FFB6 /* Select equalizer preset, e.g. 
theatre-mode */

I221 corresponds to KEY_SOUND which gets used in the kernel in
the following ways:

drivers/platform/x86/peaq-wmi.c:
Used for the Dolby button which under windows toggles through 
theater/game/speach/music mode.

drivers/media/rc/keymaps/rc-kworld-pc150u.c
73: { 0x48, KEY_SOUND}, /* switch theater mode */

drivers/media/rc/keymaps/rc-cec.c
67: { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */

drivers/media/rc/keymaps/rc-encore-enltv.c
74: { 0x4d, KEY_SOUND },/* DVD sound */





  //  key{  [ ]   }; // KEY_QUESTION
  key{  [ XF86Mail  ]   };
  key{  [ XF86Messenger ]   }; //
KEY_CHAT
@@ -210,13 +210,14 @@ xkb_symbols "evdev" {
  key{  [ XF86Battery   ]   };
  key{  [ XF86Bluetooth ]   };
  key{  [ XF86WLAN  ]   };
+key{  [ XF86UWB   ]   };


Feels weird using up a slot for a key that toggles an obsolete wireless
protocol...


The keycodes such as I247 are hardcoded to EV_FOO keycodes (with an
offset of 8) and the kernel has had:

#define KEY_UWB 239

For ages, so this is not taking a slot, it is merely adding a
mapping since both the keycode and the keysym have existed for
quite a while now.




  //  key{  [ ]   }; // KEY_VIDEO_NEXT  --  drive
next video source
  //  key{  [ ]   }; // KEY_VIDEO_PREV  --  drive
previous video source
  //  key{  [ ]   }; // KEY_BRIGHTNESS_CYCLE
--  bright up, max++ == min
  //  key{  [ ]   }; // KEY_BRIGHTNESS_ZERO
--  brightness off
  //  key{  [ ]   }; // KEY_DISPLAY_OFF  --  turn
off display
-//  key{  [ ]   }; // KEY_WIMAX
-key{  [ XF86Hibernate ]   }; //
KEY_HIBERNATE
+key{  [ XF86WWAN  ]   }; //
KEY_WWAN
+key{  [ XF86RFKill]   }; //
KEY_RFKILL
  
  key{  [ XF86Tools ]   };

  key{  [ XF86Launch5   ]   };


Cheers



Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xf86 input driver API question

2017-05-15 Thread Alan Coopersmith


On 05/14/17 11:25 PM, Martin Kepplinger wrote:

Am 2017-05-15 um 06:02 schrieb Alan Coopersmith:

On 05/14/17 08:48 AM, Martin Kepplinger wrote:

might be a dumb question, but I don't find resources: If an Xorg input
driver supports GET_ABI_MAJOR() < 14, what exactly does that mean?
xserver < 1.14 is supported? Where is the documentation on this driver
ABI?


It's out of date, but https://www.x.org/wiki/XorgModuleABIVersions/ has a
table mapping the various ABI versions to Xorg server versions.


Please update that :)


Done.


Furthermore. I'd need a list of API symbols and
functions with the server version they got introduced.


Sorry, you're going to have to use git to find that out yourself.
I don't have hours to spend generating docs that only you need.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede

KEY_SOUND, KEY_WWAN and KEY_RFKILL are used on actual devices and
current xproto master defines keysyms for these. Add mappings for
these keys.

The XF86UWB keysm exists for quite a while now, as does the KEY_SOUND
evdev code for it, so lets adds a mapping for that too.

Note that this replaces the I255 to XF86Hibernate mapping in
xkb_symbols "evdev", I don't know where that came from, but it is
wrong, I255 was until now not defined in keycodes/evdev and
KEY_HIBERNATE is not defined in linux/input-event-codes.h .

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100970
Cc: Bastien Nocera 
Cc: Benjamin Berg 
Signed-off-by: Hans de Goede 
Reviewed-by: Peter Hutterer 
---
 keycodes/evdev | 2 ++
 symbols/inet   | 7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/keycodes/evdev b/keycodes/evdev
index 624ac68..51a6e26 100644
--- a/keycodes/evdev
+++ b/keycodes/evdev
@@ -281,6 +281,8 @@ default xkb_keycodes "evdev" {
 = 251;   // #define KEY_BRIGHTNESS_CYCLE243
 = 252;   // #define KEY_BRIGHTNESS_ZERO 244
 = 253;   // #define KEY_DISPLAY_OFF 245
+= 254;   // #define KEY_WWAN246
+= 255;   // #define KEY_RFKILL  247
 
// Fake keycodes for virtual keys
 =   92;
diff --git a/symbols/inet b/symbols/inet
index 5403e77..1e06aa9 100644
--- a/symbols/inet
+++ b/symbols/inet
@@ -184,7 +184,7 @@ xkb_symbols "evdev" {
 key{  [ Print ]   };
 //  key{  [ ]   }; // KEY_HP
 key{  [ XF86WebCam]   };
-//  key{  [ ]   }; // KEY_SOUND
+key{  [ XF86AudioPreset   ]   };
 //  key{  [ ]   }; // KEY_QUESTION
 key{  [ XF86Mail  ]   };
 key{  [ XF86Messenger ]   }; // KEY_CHAT
@@ -210,13 +210,14 @@ xkb_symbols "evdev" {
 key{  [ XF86Battery   ]   };
 key{  [ XF86Bluetooth ]   };
 key{  [ XF86WLAN  ]   };
+key{  [ XF86UWB   ]   };
 //  key{  [ ]   }; // KEY_VIDEO_NEXT  --  drive next video 
source
 //  key{  [ ]   }; // KEY_VIDEO_PREV  --  drive previous 
video source
 //  key{  [ ]   }; // KEY_BRIGHTNESS_CYCLE  --  bright up, 
max++ == min
 //  key{  [ ]   }; // KEY_BRIGHTNESS_ZERO  --  brightness off
 //  key{  [ ]   }; // KEY_DISPLAY_OFF  --  turn off display
-//  key{  [ ]   }; // KEY_WIMAX
-key{  [ XF86Hibernate ]   }; // KEY_HIBERNATE
+key{  [ XF86WWAN  ]   }; // KEY_WWAN
+key{  [ XF86RFKill]   }; // KEY_RFKILL
 
 key{  [ XF86Tools ]   };
 key{  [ XF86Launch5   ]   };
-- 
2.12.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH resend xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

2017-05-15 Thread Hans de Goede

Hi,

This is a resend with the Cc to Bastien fixed up at his request as he
has some remarks.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xf86 input driver API question

Re: [PULL] Mainly hw/xwin warning fixes

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: xf86 input driver API question

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: x11perf putimagexy10 extremly slow for glamor on i965

Re: speeding up distributed multihead (xdmx)

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: Initial Haiku support

Re: Initial Haiku support

[PATCH v2 xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: [PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

Re: xf86 input driver API question

[PATCH xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

[PATCH resend xkeyboard-config] Add evdev mappings for KEY_SOUND, KEY_UWB, KEY_WWAN and KEY_RFKILL

17 matches

Site Navigation

Mail list logo

Footer information