Re: X Window: Setting up mouse scroll for OOo Calc to one raw
On Fri, Dec 30, 2011 at 05:20:27PM +0100, Csanyi Pal wrote: > Hi, > > I'm running Debian GNU/Linux SID and my X Window uses Window Maker as > a window manager. > > I'm using OpenOffice.org Calc very often and I want to setup mouse > scroll in X so when I scroll with mice then in OOo Calc raws goes > up/down only one raw and not three raws as it does at present. > > So what I'm basically seeking is a way for setting the mouse scroll > to a different value other than three lines at a time. It seems that > that this is a default value. There's no such thing as a "mouse scroll value" in X. When you rotate the mouse wheel, it sends a click on button 4 or 5. There's no such thing as a fractional click. This is a question for the people maintaining OpenOffice.org, not for the X consortium. Sincerely, Paul Vojta, vo...@math.berkeley.edu ___ 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: Key rate limit
On Mon, Mar 26, 2012 at 11:20:03AM -0500, tsuraan wrote: > > I am not sure but xset has a [r rate delay [rate]], would that be any help ? > > I believe that's for the autorepeat rate, so the rate/delay tells X > that once the key is held down for ms, it should start firing > that key at events/s (my units might be wrong though). That's > sort of the inverse of the problem I have, which is that the keyboard > seems to be sending a bunch of keypress events really quickly for a > short period of time. I have a possibly related problem. Sometimes I get keystrokes occurring via autorepeat even when no keys are pressed. They stop when I hit any other key (even shift). I've looked into it, and found out that the problem is that the keyboard (or control chip) is not sending the "break" code until the next key is hit. Then, since X apparently keeps track of which keys are pressed on its own, I get the repeated keystrokes. Is there a way of telling X to just use the autorepeat provided by the hardware? The hardware in my case is a Dell XPS M1330 laptop, purchased late 2007. The problem most often occurs when I release two (or more) keys at very close to the same time. For example, I switch Control and CapsLock (ctrl:swapcaps), and to exit a browser I hit Ctrl-W. Since the keys are so close to each other, I can just use two fingers on the same hand, and by habit I do it quickly. Then I move over to a terminal window and get a bunch of w's coming out. --Paul Vojta, vo...@math.berkeley.edu ___ 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: Key rate limit
On Thu, Mar 29, 2012 at 04:26:15PM +1000, Peter Hutterer wrote: > On Tue, Mar 27, 2012 at 12:43:49PM -0400, Paul Vojta wrote: > > On Mon, Mar 26, 2012 at 11:20:03AM -0500, tsuraan wrote: > > > > I am not sure but xset has a [r rate delay [rate]], would that be any > > > > help ? > > > > > > I believe that's for the autorepeat rate, so the rate/delay tells X > > > that once the key is held down for ms, it should start firing > > > that key at events/s (my units might be wrong though). That's > > > sort of the inverse of the problem I have, which is that the keyboard > > > seems to be sending a bunch of keypress events really quickly for a > > > short period of time. > > > > > > I have a possibly related problem. > > > > Sometimes I get keystrokes occurring via autorepeat even when no keys are > > pressed. They stop when I hit any other key (even shift). > > > > I've looked into it, and found out that the problem is that the keyboard > > (or control chip) is not sending the "break" code until the next key is hit. > > Then, since X apparently keeps track of which keys are pressed on its own, > > I get the repeated keystrokes. > > > > Is there a way of telling X to just use the autorepeat provided by the > > hardware? > > not anymore. we've removed this in server 1.6 (iirc) because that and > software autorepeat had some weird side-effects. sometimes a key would start > hw-repeating before sw-repeat kicked in, causing bursts of keys. and iirc we > had the same problem with keys not getting released correctly. > > that was a time when the whole input system was in a turmoil so it's > possible that we could fix this now but I still expect it to be a rather > large (and nasty to test) amount of work to get selective hw repeats. > > Cheers, > Peter OK, thanks for the information. Sincerely, Paul ___ 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
Implementing smooth scrolling in an X client
Folks: I've started working on implementing smooth scrolling in xdvi, and I have a question about it. When I do xinput --test 9 (where 9 is the deviceid of my Synaptics touchpad) and stroke my finger down the right-hand side of the touchpad, I get an increasing sequence of numbers: motion a[3]=1935 motion a[3]=1950 motion a[3]=1964 motion a[3]=1979 motion a[3]=2007 motion a[3]=2017 motion a[3]=2034 motion a[3]=2062 motion a[3]=2088 motion a[3]=2124 motion a[3]=2154 motion a[3]=2185 motion a[3]=2210 etc. So far I've modified xdvi so that I can get a similar printout from xdvi. I guess that what I'm supposed to do with these numbers is keep track of the most recently reported number, and scroll based on the differences between the numbers. But now if I move my mouse to some other window (e.g., xterm), scroll in that window for a while, and then move back, the numbers reported to xdvi would reflect the scrolling activity done in the other window. So I would need to keep track of EnterNotify events for each window for which I'm doing smooth scrolling, and set a flag each time such an event is received. A problem with this (other than the extra programming effort required) is that on four-button Synaptics touchpads, the first button press of the third or fourth button after returning to the xdvi window would (I think) have no effect anymore. (More generally, the first scrolling distance would be ignored for every return to the window, but would not be noticeable unless it was produced by a button press or simulated button press.) Is this correct? And, more to the point, is there some way by which I could just receive the deltas of the scrolling valuators for when the pointer is in the designated window? I am using Debian on x86_64, with the following package versions: xserver-xorg-core 2:1.12.1.902-1 xserver-xorg-input-synaptics 1.6.1-1 xinput 1.6.0-1 Sincerely, Paul Vojta ___ 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: Implementing smooth scrolling in an X client
On Tue, Jun 12, 2012 at 11:25:08AM +1000, Peter Hutterer wrote: > On Mon, Jun 04, 2012 at 06:50:47PM -0400, Paul Vojta wrote: [snip] > > So I would need to keep track of EnterNotify events for each window for > > which I'm doing smooth scrolling, and set a flag each time such an event > > is received. > > yes, this is a bug in the protocol and that behaviour is what GTK has to do > as well. > http://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html Thanks very much for that reference -- it's very helpful. > > A problem with this (other than the extra programming effort required) > > is that on four-button Synaptics touchpads, the first button press of > > the third or fourth button after returning to the xdvi window would > > (I think) have no effect anymore. (More generally, the first scrolling > > distance would be ignored for every return to the window, but would not > > be noticeable unless it was produced by a button press or simulated button > > press.) > > > > Is this correct? > > are you talking about the touchpads that have separate scroll buttons? I'd > not worry too much about those, I think even the newest ones are several > years old now (to the point that the next version of synaptics won't support > the scroll buttons anymore). Yes, but also things like RTCornerButton=4, etc. Also, what happens if you have a traditional wheel mouse in addition to a touchpad? > > And, more to the point, is there some way by which I could just receive the > > deltas of the scrolling valuators for when the pointer is in the designated > > window? > > you can't really get the deltas only, you'll always have to calculate them > from the previous value. your only option for not skipping the first event > is to run XIQueryDevice after an EnterEvent to get the current value on the > valuator so you can use that first event with that delta. Of course, that is > prone to race conditions so you have to work around them too. OK, thanks. > sorry :( Any plans to change the spec anytime soon (e.g., for X11R7.8 or XI 2.3)? --Paul Vojta, vo...@math.berkeley.edu ___ 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
XInput 2.1 valuator values when resuming from SlaveSwitch
Dear all: I've been working on adding "smooth scrolling" to xdvi (after a long hiatus), and I'm encountering some glitches when switching pointer devices. Specifically, when a slave is being switched back on, the scroll valuators are always reported as having value 0 in the classes field of the XIDeviceChanged event. When using the evdev driver, however, the valuator values are the same as when the device was last used, and so this causes a large scroll glitch when resuming using the device. (When using the synaptics driver, the values are always reset, so there is no problem in that case.) (I'm only checking the vertical scroll valuator so far, but I expect that the same would be true for the horizontal scroll valuator.) I'm using version 1.12.4 of the server (Debian version 2:1.12.4-4), version 2.7.0 of evdev (Debian version 1:2.7.0-1+b1), and version 1.6.2 of the synaptics driver (Debian version 1.6.2-2). The hardware is x86_64. Comments, anyone? In particular, is it correct to assume that the classes field of the XIDeviceChanged event should contain the correct value for the valuator, and that the behavior with evdev is buggy? --Paul Vojta, vo...@math.berkeley.edu ___ 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: XInput 2.1 valuator values when resuming from SlaveSwitch
On Wed, Mar 13, 2013 at 02:18:26PM +1000, Peter Hutterer wrote: > On Tue, Mar 12, 2013 at 12:53:33PM -0700, Paul Vojta wrote: > > Dear all: > > > > I've been working on adding "smooth scrolling" to xdvi (after a long > > hiatus), and I'm encountering some glitches when switching pointer devices. > > > > Specifically, when a slave is being switched back on, the scroll valuators > > are always reported as having value 0 in the classes field of the > > XIDeviceChanged event. > > > > When using the evdev driver, however, the valuator values are the same > > as when the device was last used, and so this causes a large scroll > > glitch when resuming using the device. (When using the synaptics driver, > > the values are always reset, so there is no problem in that case.) > > (I'm only checking the vertical scroll valuator so far, but I expect > > that the same would be true for the horizontal scroll valuator.) > > unfortunately, that is the correct behaviour > http://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html > > the reset should not happen in synaptics, that's likely a bug in the driver. No, it's not the problem with leaving, scrolling elsewhere, and then re-entering a window. I've encountered and (imperfectly) dealt with that problem already. Rather, it's a problem with SlaveSwitch. It can happen even if the pointer never leaves the window. In more detail: I have my laptop's built-in Synaptics touchpad (with the synaptics driver), and an external USB mouse (Cirque USB GlidePoint, 0488:0022) (with the evdev driver -- it behaves just like a normal mouse, except that it doesn't cause a SlaveSwitch every time I jiggle the table). I can start up xdvi, move the pointer into the window, scroll down with the external (Cirque) mouse, switch to the built-in touchpad, resume using the external mouse, and then when I scroll the mouse with it I get a huge scroll effect instead of just one click. There *is* a place in the SlaveSwitch XI2-event for a valuator value, but it's always zero. --Paul Vojta, vo...@math.berkeley.edu ___ 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: XInput 2.1 valuator values when resuming from SlaveSwitch
On Thu, Mar 14, 2013 at 10:37:05AM +1000, Peter Hutterer wrote: > On Wed, Mar 13, 2013 at 12:12:27AM -0700, Paul Vojta wrote: > > On Wed, Mar 13, 2013 at 02:18:26PM +1000, Peter Hutterer wrote: > > > On Tue, Mar 12, 2013 at 12:53:33PM -0700, Paul Vojta wrote: > > > > Dear all: > > > > > > > > I've been working on adding "smooth scrolling" to xdvi (after a long > > > > hiatus), and I'm encountering some glitches when switching pointer > > > > devices. > > > > > > > > Specifically, when a slave is being switched back on, the scroll > > > > valuators > > > > are always reported as having value 0 in the classes field of the > > > > XIDeviceChanged event. > > > > > > > > When using the evdev driver, however, the valuator values are the same > > > > as when the device was last used, and so this causes a large scroll > > > > glitch when resuming using the device. (When using the synaptics > > > > driver, > > > > the values are always reset, so there is no problem in that case.) > > > > (I'm only checking the vertical scroll valuator so far, but I expect > > > > that the same would be true for the horizontal scroll valuator.) > > > > > > unfortunately, that is the correct behaviour > > > http://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html > > > > > > the reset should not happen in synaptics, that's likely a bug in the > > > driver. > > > > No, it's not the problem with leaving, scrolling elsewhere, and then > > re-entering a window. I've encountered and (imperfectly) dealt with that > > problem already. > > > > Rather, it's a problem with SlaveSwitch. It can happen even if the > > pointer never leaves the window. > > > > In more detail: I have my laptop's built-in Synaptics touchpad (with the > > synaptics driver), and an external USB mouse (Cirque USB GlidePoint, > > 0488:0022) (with the evdev driver -- it behaves just like a normal mouse, > > except that it doesn't cause a SlaveSwitch every time I jiggle the table). > > > > I can start up xdvi, move the pointer into the window, scroll down with the > > external (Cirque) mouse, switch to the built-in touchpad, resume using the > > external mouse, and then when I scroll the mouse with it I get a huge > > scroll > > effect instead of just one click. > > > > There *is* a place in the SlaveSwitch XI2-event for a valuator value, but > > it's always zero. > > confirmed, please file a bug and assign it to me > > Cheers, >Peter Done: Bug 62321 (I didn't see a way to assign it to you, and I'm not sure I selected the right component of the X server.) Thanks! --Paul ___ 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: Fw: Xt / Motif C++ application hangs in the XtDispatchEvent call
On Mon, Dec 12, 2016 at 08:15:14AM -, Subrata Dasgupta wrote: > Hope fully this should be posted on xorg@lists.x.org so that all can see.. > Sorry I missed to post there.. > > Note: Forwarded message attached > > -- Original Message -- > > From: "Subrata Dasgupta"subrata_u...@rediffmail.com > To: wha...@bfs.de,thomas.luebk...@gmx.de,alan.coopersm...@oracle.com > Subject: Re: Xt / Motif C++ application hangs in the XtDispatchEvent call > From: Subrata Dasgupta > To: wha...@bfs.de, thomas.luebk...@gmx.de, alan.coopersm...@oracle.com > Subject: Re: Xt / Motif C++ application hangs in the XtDispatchEvent call > > > Hi All, > > Let me reply to you one by one in a single mail , because multiple mails > seems to create lots of confusion. > > Walter , > > 1> Recompile of the application is not possible because few old 3rd party > libs are now not available in 64 bit format. I can not change this.. > > 2> I do not think this is a library loading issue ... ldd revels application > is loading the correct library from correct location. So there is no question > of mix. Another problem that could come up is that in one part of the code a function argument is declared as a 32-bit quantity, and elsewhere it is 64 bits. (Or vice versa.) This can occur, e.g., if #include files are included differently in different source files. I don't know of any systematic way of checking this. Just standard debugging techniques, but check that function argument values are the same in the calling process and in the function itself. --Paul Vojta, vo...@math.berkeley.edu > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: phantom ESC key stream activity
On Thu, Jan 05, 2017 at 01:10:22PM -0500, Trevor Woerner wrote: > Hi Vladimir, > > (I hope you don't mind me steering this conversation back to the mailing > list?) > > On Thu 2017-01-05 @ 12:33:55 PM, Vladimir Dergachev wrote: > > X11 should be receiving the stream via Linux input layer. I would suggest > > to check for changes to Linux kernel and, in particular, any power saving > > settings. > > Yes, there was a kernel update for openSUSE 42.1 recently, 3 days ago, which I > applied at that time. When you say "receiving the stream", do you mean receiving the stream of spurious Esc characters? If so, then they're probably generated within the X server itself. The X server is receiving a "make contact" code for the Escape key but no corresponding "break contact" key, so it's doing autorepeat. To check whether this is what is happening, try fiddling with the -arinterval argument to the X server and see if it changes the frequency of the spurious Esc characters. That's the X server command line, so it's probably buried in gnome or xfce or kde somewhere, unless you're starting X via startx. I don't know if it's possible to change this in a running X server. --Paul Vojta, vojta at math dot berkeley period edu ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: phantom ESC key stream activity
On Thu, Jan 05, 2017 at 12:42:42PM -0800, Paul Vojta wrote: > ... I don't know if it's possible to change this in a > running X server. I remember now: use the xset command. --Paul Vojta, vojta at math dot berkeley period edu ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: TWM is lacking libxinerama
On Fri, Sep 07, 2018 at 10:06:24AM -0700, Alan Coopersmith wrote: [snip] > In any case, twm has no active developers working on it, so I'd suggest > choosing > a different window manager if you want features twm lacks. Can you suggest any? Paul Vojta, vojta at math dot berkeley dot edu ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: bitmaps or no?
On Tue, Dec 01, 2020 at 07:36:20PM -0500, James K. Lowden wrote: > I have a basic how-does-one question about scrolling text in a window. > [snip] > > What's the accepted way to do it? XCopyArea > --jkl Sincerely, Paul Vojta ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
