Re: Consistent handling of USB device buttons
> > use XI2 and deviceid in events, then you know that the volume up was hit on > this particular device. clients may not make use of this right now, but the > infrastructure is in place. Thanks a lot. This is exactly the piece of information I was looking for. > > > file this as bug and attach an evemu recording, I'll have a look at it. > http://people.freedesktop.org/~whot/evemu/ Yep, created https://bugs.freedesktop.org/show_bug.cgi?id=53907 Regards, Alex ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to edit Drawable/XdbeBackBuffer data?...
On 08/21/2012 03:56 PM, Lee Fallat wrote:
Alright, well I've decided to take another approach. I'm XGetImage()ing
the root window, then I darken my pixels, then, I go to store the data
in a Drawable via XPutImage, but this Drawable isn't retaining the data,
it's just white when I XCopyArea() over to what I want shown. Any
suggestions/reasons why this is happening?
Code sample:
static XImage *xi;
void XTintBG(Monitor *m, int x, int y, int w, int h) {
unsigned long new_color;
unsigned long r,g,b;
XCopyArea(dpy, root, m->barwin, dc.gc, x, y, w, h, x, y);
xi = XGetImage(dpy, m->barwin, x, y, w, h, AllPlanes, XYPixmap);
You almost certainly want ZPixmap rather than XYPixmap. ZPixmap is your
normal n-bits-per-pixel, pixels in scanline order image format.
XYPixmap is the oh-god-kill-me-now image format.
The rest of the code seems reasonable, so try fixing that first.
If you need better performance and are willing to make your code even
more complicated, you could bind the drawable in question using
GLX_EXT_texture_from_pixmap, either as a pixmap directly, or by using
the Composite extension to redirect the window you want and using its
backing pixmap. Then you can do much more complicated rendering using
it as an OpenGL texture. This unfortunately does not work on the root
window but you could copy the root window's contents into a pixmap and
then use that.
Adam's suggestion of using Render would be simpler if you can find a
blending op that does what you want.
-- Aaron
for(int pix_y = 0; pix_y < h; pix_y++) {
for(int pix_x = 0; pix_x < w; pix_x++) {
new_color = XGetPixel(xi, pix_x, pix_y);
r = g = b = 0x;
r = (new_color & 0x00FF) >> 16;
g = (new_color & 0xFF00) >> 8;
b = (new_color & 0x00FF) >> 0;
r -= 32;
g -= 32;
b -= 32;
if(r > 255) r = 255;
if(r < 0) r = 0;
if(g > 255) g = 255;
if(g < 0) g = 0;
if(b > 255) b = 255;
if(b < 0) b = 0;
new_color = r << 16;
new_color = new_color | (g << 8);
new_color = new_color | (b << 0);
XPutPixel(xi, pix_x, pix_y, new_color);
}
}
XPutImage(dpy, m->barwin, dc.gc, xi, 0, 0, 0, 0, m->ww, bh);
XCopyArea(dpy, m->barwin, dc.bg , dc.gc, 0, 0, m->ww,
bh, 0, 0);
}
int ftime = 1;
void
drawbar(Monitor *m) {
int x;
unsigned int i, occ = 0, urg = 0;
XftColor *col;
Client *c;
if(ftime == 1) {
ftime = 0;
XTintBG(m, 0, 0, m->ww, bh);
}
XCopyArea(dpy, dc.bg , dc.drawable, dc.gc, 0, 0, m->ww,
bh, 0, 0);
}
On Mon, Aug 20, 2012 at 3:17 PM, Adam Jackson mailto:a...@redhat.com>> wrote:
On 8/20/12 2:08 PM, Lee Fallat wrote:
Hey,
I'm trying to darken/lighten the image data in a
Drawable/XdbeBackBuffer.
Any ideas on how to get access to the data?...I've done an
XGetImage() on
Drawable but that really slows down the application I'm editing...
That is, in fact, how you do it. GetImage is not fast. ShmGetImage
is faster, and as fast as you're going to get, if you insist on
doing this by pulling all the pixels down to the client and then
pushing them back up.
You may instead wish to use the Render extension, which gives you
the usual set of Porter-Duff blend operations, and which runs in the
server so you're not copying all that data around.
- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On Tue, Aug 21, 2012 at 05:54:18AM +, Alex Dubov wrote: > Peter Hutterer who-t.net> writes: > > > > > > > 1. Buttons have session global effect and there's no easy, nor stable way > > > to limit their effect to a particular device. > > > > I don't understand this bit. can you paraphrase? > > For example, if I press a button on a headset and say it maps to > "XF86VolumeUp", how does the mixer application is supposed to know > which channel to adjust? I would expect it to only affect the headset, not > the "master" channel which is normally set to built-in audio card. use XI2 and deviceid in events, then you know that the volume up was hit on this particular device. clients may not make use of this right now, but the infrastructure is in place. > > evdev will set up BTN_0...BTN_TASK as buttons on a device. anything else > > should be a keyboard. especially KEY_CAMERA should be a key. what specific > > device has the camera button set up as mouse button? > > My most recent problem was with Plantronics Audio 648 USB headset (works on > XP out of the box). It's got 4 buttons ["call", "volume up", "volume down" > and "mic mute"], which for some reason are mapped by evdev to mouse buttons > [8, 3, 2, 1]. file this as bug and attach an evemu recording, I'll have a look at it. http://people.freedesktop.org/~whot/evemu/ Cheers, Peter > As per point 1 above, mouse button presses generated by headset seem > indistinguishable from normal mouse key presses when applications are > concerned (with expected funny results). ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to edit Drawable/XdbeBackBuffer data?...
Alright, well I've decided to take another approach. I'm XGetImage()ing the
root window, then I darken my pixels, then, I go to store the data in a
Drawable via XPutImage, but this Drawable isn't retaining the data, it's
just white when I XCopyArea() over to what I want shown. Any
suggestions/reasons why this is happening?
Code sample:
static XImage
*xi;
void XTintBG(Monitor *m, int x, int y, int w, int h)
{
unsigned long
new_color;
unsigned long
r,g,b;
XCopyArea(dpy, root, m->barwin, dc.gc, x, y, w, h, x,
y);
xi = XGetImage(dpy, m->barwin, x, y, w, h, AllPlanes,
XYPixmap);
for(int pix_y = 0; pix_y < h; pix_y++)
{
for(int pix_x = 0; pix_x < w; pix_x++)
{
new_color = XGetPixel(xi, pix_x,
pix_y);
r = g = b =
0x;
r = (new_color & 0x00FF) >>
16;
g = (new_color & 0xFF00) >>
8;
b = (new_color & 0x00FF) >>
0;
r -=
32;
g -=
32;
b -=
32;
if(r > 255) r =
255;
if(r < 0) r =
0;
if(g > 255) g =
255;
if(g < 0) g =
0;
if(b > 255) b =
255;
if(b < 0) b =
0;
new_color = r <<
16;
new_color = new_color | (g <<
8);
new_color = new_color | (b <<
0);
XPutPixel(xi, pix_x, pix_y,
new_color);
}
}
XPutImage(dpy, m->barwin, dc.gc, xi, 0, 0, 0, 0, m->ww,
bh);
XCopyArea(dpy, m->barwin, dc.bg, dc.gc, 0, 0, m->ww, bh, 0,
0);
}
int ftime =
1;
void
drawbar(Monitor *m)
{
int
x;
unsigned int i, occ = 0, urg =
0;
XftColor
*col;
Client
*c;
if(ftime == 1)
{
ftime =
0;
XTintBG(m, 0, 0, m->ww,
bh);
}
XCopyArea(dpy, dc.bg, dc.drawable, dc.gc, 0, 0, m->ww, bh, 0, 0);
}
On Mon, Aug 20, 2012 at 3:17 PM, Adam Jackson wrote:
> On 8/20/12 2:08 PM, Lee Fallat wrote:
>
>> Hey,
>>
>> I'm trying to darken/lighten the image data in a Drawable/XdbeBackBuffer.
>> Any ideas on how to get access to the data?...I've done an XGetImage() on
>> Drawable but that really slows down the application I'm editing...
>>
>
> That is, in fact, how you do it. GetImage is not fast. ShmGetImage is
> faster, and as fast as you're going to get, if you insist on doing this by
> pulling all the pixels down to the client and then pushing them back up.
>
> You may instead wish to use the Render extension, which gives you the
> usual set of Porter-Duff blend operations, and which runs in the server so
> you're not copying all that data around.
>
> - ajax
>
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xorg-server 1.12.99.905
Aaron noticed that the ABI version needed to be bumped before the release, so I'm pushing that out in this RC. There haven't been any ABI/API changes since RC1, of course, we just hadn't set the ABI version at that point. Otherwise, not a huge number of changes; that's to be expected during this final bug-fixing phase of the 1.13 release. Thanks to all for testing and sending patches! Aaron Plattner (1): xfree86: Bump extension ABI to 7.0 Jeremy Huddleston (1): XQuartz: Fix build regression for GlxExtensionInit Jeremy Huddleston Sequoia (4): XQuartz: console_redirect: Set the correct location for reading into the buffer XQuartz: console_redirect: Properly zero-out the tail of the array on realloc() XQuartz: Use asl_log_descriptor on Mountain Lion XQuartz: Use asl_log_descriptor for children as well Keith Packard (4): Only free Render filter names on last screen close Close GPU screens before core screens Kludge -- Call RandR screen before cleaning up xf86 crtcs Relase 1.12.99.905 Paul Berry (1): glx: Skip multisampled configs when matching pre-existing X visuals. Simon Schubert (1): fb: reorder Bresenham error correction to avoid overshoot. git tag: xorg-server-1.12.99.905 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.99.905.tar.bz2 MD5: 7e7bdd9a6721ba3eb0ae518c7f0a7229 xorg-server-1.12.99.905.tar.bz2 SHA1: ec6cce88f47e4cb7e246c4eb0c5993ee93ed95d0 xorg-server-1.12.99.905.tar.bz2 SHA256: 6949c4978aa6ba051955a20f0af27b0765e04a39346af29672547b26097784e3 xorg-server-1.12.99.905.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.99.905.tar.gz MD5: c2ecb5bf5061bf4378613c9257e66e23 xorg-server-1.12.99.905.tar.gz SHA1: 9b0f53672330602d5fa2bb670dab590c4690b24a xorg-server-1.12.99.905.tar.gz SHA256: 5d8cd718ccfe5f656ccf83bf565feda17a1b6e19532219318a7c65715e59a06b xorg-server-1.12.99.905.tar.gz -- keith.pack...@intel.com pgpDYG82Ko0jI.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: why does -sharevts is so important for multseat setup?
Thanks for the ansewr. why won't X select different /dev/ttyXX An wise Scandinavian old man once said: "in the end, everything is going to be alright" From: Aivils Štoss To: "stompdagg...@yahoo.com" Cc: "xorg@lists.x.org" Sent: Tuesday, August 21, 2012 8:44 PM Subject: Re: why does -sharevts is so important for multseat setup? Citējot "stompdagg...@yahoo.com" : > Hello, > > > I have a multiseat setup and where I'm experiencing lose of keystrokes in the > second seat. > I'm using hotpluged (via udev) feature, what I do noticed that if I press > CRTL+ALT+F1on seat 2, seat1 goes to cli. > for now I'm putting udev aside on this matter and try to concentrate on X > part, while searching the web I've found a article that mentions that such > issue can happen due to the -sharevts. > > I wanted to know, why multiseat setup needs to share vts? why if I take out > this feature, one of the seats doesn't lights up? > Normally kernel sends key press events to applications via /dev/ttyXX device files. Each Xorg open single /dev/ttyXX file and receive keyboard events. /dev/ttyXX was designed to support single active application like Xorg. When one X became active then another suspended. So single end-user can easy switch between multiple X instances. Multiseat have another mission. That is a reason of -sharevts. Active X does not try to suspend another X via /dev/ttyXX. In reality /dev/ttyXX stay unused under multiseat, because every X receive events from keyboards via /dev/input/eventXX device files. As alternative You can hack the Linux kernel with faketty (outdated) module. Aivils Stoss ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: stompdagg...@yahoo.com___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: why does -sharevts is so important for multseat setup?
Citējot "stompdagg...@yahoo.com" : Hello, I have a multiseat setup and where I'm experiencing lose of keystrokes in the second seat. I'm using hotpluged (via udev) feature, what I do noticed that if I press CRTL+ALT+F1on seat 2, seat1 goes to cli. for now I'm putting udev aside on this matter and try to concentrate on X part, while searching the web I've found a article that mentions that such issue can happen due to the -sharevts. I wanted to know, why multiseat setup needs to share vts? why if I take out this feature, one of the seats doesn't lights up? Normally kernel sends key press events to applications via /dev/ttyXX device files. Each Xorg open single /dev/ttyXX file and receive keyboard events. /dev/ttyXX was designed to support single active application like Xorg. When one X became active then another suspended. So single end-user can easy switch between multiple X instances. Multiseat have another mission. That is a reason of -sharevts. Active X does not try to suspend another X via /dev/ttyXX. In reality /dev/ttyXX stay unused under multiseat, because every X receive events from keyboards via /dev/input/eventXX device files. As alternative You can hack the Linux kernel with faketty (outdated) module. Aivils Stoss ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On 21/08/12 18:19 , Xavier Bestel wrote: On Tue, 2012-08-21 at 13:16 +1000, Peter Hutterer wrote: 1. Buttons have session global effect and there's no easy, nor stable way to limit their effect to a particular device. I don't understand this bit. can you paraphrase? I guess he means if you have two webcams with a "mute" button, there's no way to associate the button with a particular webcam. To X11 it's just a global mute button. using XI2, you get the deviceid with each event, so that's easy enough to work around. whatever listens to it at the moment (e.g. gnome-settings-daemon) may not do this, but X certainly makes it possible. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
On Tue, 2012-08-21 at 13:16 +1000, Peter Hutterer wrote: > > 1. Buttons have session global effect and there's no easy, nor stable way to > > limit their effect to a particular device. > > I don't understand this bit. can you paraphrase? I guess he means if you have two webcams with a "mute" button, there's no way to associate the button with a particular webcam. To X11 it's just a global mute button. Xav ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] glamor 0.5.0
On Tue, Aug 21, 2012 at 12:51 PM, Rémi Cardona wrote: > Hi Zhigang, > > Le vendredi 10 août 2012 à 18:37 +0800, Zhigang Gong a écrit : >> tar ball is at: >> >> http://cgit.freedesktop.org/xorg/driver/glamor/snapshot/glamor-0.5.tar.gz > > This is a git snapshot, not a tarball made using automake's "make dist" > like all X.org modules use. I forgot to make and upload the tarballs. Thanks for your reminder. > > Is one planned? sure, here you are. git tag: glamor-egl-0.5.0 http://xorg.freedesktop.org/archive/individual/driver/glamor-egl-0.5.0.tar.bz2 MD5: 7dc2b4e0d8d286531c433893945a3837 glamor-egl-0.5.0.tar.bz2 SHA1: 6495d1a2054e2a8e0f7e01bc7e3345cd50d21972 glamor-egl-0.5.0.tar.bz2 SHA256: 5dc8679ccb3e42bf431b6316c7907b9df2db89745d523e04721f34aee6c84991 glamor-egl-0.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/glamor-egl-0.5.0.tar.gz MD5: 8f8f58cbf661a6eb70785864ebf5153f glamor-egl-0.5.0.tar.gz SHA1: 08366dd52b5f5812847f20a1252a86100766f8ab glamor-egl-0.5.0.tar.gz SHA256: e7ed6ead72a44bcd68d837eb5bf133f760be1e5fb42907cf1bb06ba5f4d6dc18 glamor-egl-0.5.0.tar.gz > > Cheers, > > Rémi > > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.x.org/mailman/listinfo/xorg > Your subscription address: zhigang.g...@gmail.com ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Consistent handling of USB device buttons
Peter Hutterer who-t.net> writes: > > > > 1. Buttons have session global effect and there's no easy, nor stable way > > to limit their effect to a particular device. > > I don't understand this bit. can you paraphrase? For example, if I press a button on a headset and say it maps to "XF86VolumeUp", how does the mixer application is supposed to know which channel to adjust? I would expect it to only affect the headset, not the "master" channel which is normally set to built-in audio card. > evdev will set up BTN_0...BTN_TASK as buttons on a device. anything else > should be a keyboard. especially KEY_CAMERA should be a key. what specific > device has the camera button set up as mouse button? My most recent problem was with Plantronics Audio 648 USB headset (works on XP out of the box). It's got 4 buttons ["call", "volume up", "volume down" and "mic mute"], which for some reason are mapped by evdev to mouse buttons [8, 3, 2, 1]. As per point 1 above, mouse button presses generated by headset seem indistinguishable from normal mouse key presses when applications are concerned (with expected funny results). Regards, Alex > > Cheers, >Peter > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Difficulty running X11 on Toshiba Satellite A10-S1692 running FreeBSD 9.0
On Mon, Aug 20, 2012 at 12:04 PM, Bernard Higonnet wrote: > There appeared to be no errors in any of the install, Xorg -configure is > happy. > > But when I run Xorg -config xorg.conf.new (with or without -retro) screen > goes black, computer freezes and I can only restart it by first powering > off... > > I have searched for configuration files for this machine without success. > > The output of pciconf says > > vgapci0@pci0:0:2:0: class=0x03 card=0x00021179 chip=0x35828086 > rev=0x01 hdr=0x00 > vgapci1@pci0:0:2:1: class=0x038000 card=0x00021179 chip=0x35828086 > rev=0x01 hdr=0x00 OK. Maybe a bit more information would help. What do you get from 'pciconf -lv'? Can you start Xorg without trying to create a config file? Most systems today will start out of the box and the configuration generator has been know to lock up. What about make.conf? Do you have WITH_NEW_XORG in it or any other options tied to video or Xorg? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] glamor 0.5.0
Hi Zhigang, Le vendredi 10 août 2012 à 18:37 +0800, Zhigang Gong a écrit : > tar ball is at: > > http://cgit.freedesktop.org/xorg/driver/glamor/snapshot/glamor-0.5.tar.gz This is a git snapshot, not a tarball made using automake's "make dist" like all X.org modules use. Is one planned? Cheers, Rémi ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
