Re: Corrupt window
Andrew Kurn composed on 2019-06-18 20:16 (UTC-0700): > On Tue 18 Jun 2019 10:50 -0500, Chris Sorenson wrote: >>> Mon, 17 Jun 2019 15:01:50 -0700 Andrew Kurn composed: >>> I'm using the version of X current for Debian Jessie. >>> I find that windows are sometimes corrupted. The typical case >>> is in XTerm, when the bottom line is covered by a copy of the >>> second-last line. It happens a little more than half the >>> time, so some sort of race condition. >>> It is not confined to XTerm; Emacs and Aisleriot show some >>> of the same behavior. >>> In all cases, moving the window will cure the problem. The >>> redraw is correct. >>> So my conclusion is it's a fault in X. I've never had to >>> report an X bug before. Unlikely a bug report for a product as old as Jessie would get fixed. Versions have advanced considerably since. It may have been a bug that is long since fixed. >>> If you will give me a list of info to provide, I will send >>> it in a later message. >> Your graphics hardware? If you don't know, `lspci -vv` will list everything >> connected to your PCI bus, but please parse out the graphics info rather >> than replying with the whole list. Lspci doesn't report the kernel driver or the DDX (X driver dependent on the kernel's modesetting functionality, KMS). > 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated > Graphics Controller (rev 02) (prog-if 00 [VGA controller]) ... > Kernel driver in use: i915 > 00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics > Controller (rev 02) You may find switching DDX would clear up the problem. In Jessie the Intel DDX is in xserver-xorg-video-intel, while the modesetting DDX is in xserver-xorg-video-modesetting. Switching can be as simple as purging one and/or installing the other. I have the same GPU but no OS so old, and have seen no evidence of the corruption you describe using the modesetting DDX: # inxi -GxxSM System:Host: gx745 Kernel: 4.12.14-lp151.28.7-default x86_64 bits: 64 compiler: gcc v: 7.4.0 Desktop: KDE 3.5.10 tk: Qt 3.3.8c wm: kwin dm: N/A Distro: openSUSE Leap 15.1 Machine: Type: Desktop System: Dell product: OptiPlex 745 v: N/A serial: 901DSC1 Chassis: type: 15 serial: 901DSC1 Mobo: Dell model: 0GX297 serial: ..CN6986173Q1835. BIOS: Dell v: 2.6.2 date: 08/12/2008 Graphics: Device-1: Intel 82Q963/Q965 Integrated Graphics vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2992 Display: server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa alternate: intel resolution: 1680x1050~60Hz OpenGL: renderer: Mesa DRI Intel 965Q v: 2.1 Mesa 18.3.2 direct render: Yes # lspci -vv 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) ... 00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ 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: xorg Digest: Corrupt window
> >Message: 1 > >Date: Mon, 17 Jun 2019 15:01:50 -0700 > >From: Andrew Kurn > >Subject: Corrupt window > > > >I'm using the version of X current for Debian Jessie. > > > >I find that windows are sometimes corrupted. The typical case > >is in XTerm, when the bottom line is covered by a copy of the > >second-last line. It happens a little more than half the > >time, so some sort of race condition. > > > >It is not confined to XTerm; Emacs and Aisleriot show some > >of the same behavior. > > > >In all cases, moving the window will cure the problem. The > >redraw is correct. > > > >So my conclusion is it's a fault in X. I've never had to > >report an X bug before. > > > >If you will give me a list of info to provide, I will send > >it in a later message. > > > >Otherwise, thanks for your attention. > > > >Andrew > > On Tue 18 Jun 2019 10:50 -0500, Chris Sorenson wrote: > Date: Tue, 18 Jun 2019 10:50:40 -0500 > From: Chris Sorenson > > > > Your graphics hardware? If you don't know, `lspci -vv` will list everything > connected to your PCI bus, but please parse out the graphics info rather > than replying with the whole list. --- 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Dell Device 01da Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) Subsystem: Dell Device 01da Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- --- > > Also, on the very unlikely possibility that it's a termcap issue, from an > xterm window; what does `echo $TERM` tell you? xterm-color OK so far? Andrew ___ 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: libXt release
On Tue, Jun 18, 2019 at 07:18:21AM -0400, Thomas Dickey wrote: > On Tue, Jun 18, 2019 at 05:37:40AM -0400, Thomas Dickey wrote: > > On Mon, Jun 17, 2019 at 10:08:21AM -0400, Matt Turner wrote: > > > On Mon, Jun 17, 2019 at 4:57 AM Thomas Dickey wrote: > > > > > > > > On Sun, Jun 16, 2019 at 08:08:42PM -0400, Thomas Dickey wrote: > > > > > On Thu, Jun 13, 2019 at 03:43:04PM -0400, Thomas Dickey wrote: > > > > > > - Original Message - > > > > > > | From: "Matt Turner" > > > > > > | To: "Thomas Dickey" > > > > > > | Cc: "xorg-devel" > > > > > > | Sent: Thursday, June 13, 2019 1:47:04 PM > > > > > > | Subject: libXt release > > > > > > > > > > > > | Hi Thomas, > > > > > > | > > > > > > | I'd like to do a tarball release of libXt since there are now > > > > > > quite a > > > > > > | few commits since 1.1.5, released in 2015. Are you okay with me > > > > > > making > > > > > > | a 1.2.0 release now, or is there anything else you would want to > > > > > > get > > > > > > | into a new release? > > > > > > > > > > > > I've been working on some scripts to check for > > > > > > breakage in the specification document - might have some fixes > > > > > > there. > > > > > > > > > > > > I'll review the current state on the weekend, to give better advice. > > > > > > > > > > I think it's in good shape. Because of the interface change (using > > > > > const), I was going to suggest that it should be 1.2.0 > > > > > > > > I added a merge request for "1.2.0", which I'm testing, > > > > should be done tomorrow early (in case someone finds an issue). > > > > > > Thanks. Are you familiar with the Xorg release scripts [0]? There's a > > > wiki page at [1] that has instructions. > > > > > > If for any reason you have trouble making the release or uploading the > > > tarball, let me know and I'll be happy to handle it. > > > > > > [0] https://gitlab.freedesktop.org/xorg/util/modular/ > > > > hmm - in a quick check, there's something amiss with the distcheck step > > because it's not picking up the right path to the makestrs utility > > (or failing to build it in parallel, etc). That's with my Debian/testing > > machine. fixed that... But I don't have ssh access to the server to upload files. What is the next step? -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ 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: Can not see mouse pointer
On 6/18/19 8:16 AM, Laurentiu-Cristian Duca wrote: > when I run startx, the mouse pointer is not visible anymore. The > athena application > appears on the screen but I can not press the button because it is no > mouse on the screen. > >Any ideas on how to get mouse on the screen without calling xterm ? Modern X servers do not draw the mouse cursor until a program sets the cursor image. So you should be able to get the mouse on screen with: - modifying the athena application to set a cursor image - starting the X server with the -retro flag to get the old behavior with the default X cursor shown at startup (see the Xserver(1) man page for the -retro flag) - running another program that sets the cursor image, such as xsetroot -cursor_name bogosity (See /usr/include/X11/cursorfont.h for the available names or https://www.oreilly.com/library/view/x-window-system/9780937175149/ChapterD.html for pictures.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ 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: Fault reports and bug fixes and expectations
Am 18.06.2019 18:33, schrieb Adam Jackson: > On Mon, 2019-06-17 at 10:31 +, Wheatley, Martin R wrote: > >> If Oracle will only take the Xorg source rather (as opposed to fixing >> it - or even discussing a fix with Xorg - and pushing the fix back to >> Xorg) who and when will the issue be fixed so that I can put pressure >> on Oracle to generate a patch from the new Xorg code thus improving >> the reliability of my control room operation? > > The X.Org Foundation does not have development resources of its own. > Individual and corporate contributors do work on the various > components, but usually that work is prioritized by individual or > corporate interest. (For example, my employer has very little interest > in, say, xcalc, and neither do I, so I tend not to notice issues > reported there.) As with many open source projects, patches carry more > weight than bug reports. Changing to gitlab has (hopefully) made it > significantly easier to submit drive-by fixes for issues like this. > > To this specific bug: ooh, you can fix this by deletion, my favorite > kind of fix. I think this will resolve it: > > https://gitlab.freedesktop.org/xorg/app/xauth/merge_requests/1 > > xauth looks like it has a few other minor fixes that have accumulated, > I'll be happy to push out a new release once that MR is resolved. I'm > not especially familiar with Solaris these days, but xauth itself has > changed so little that I suspect you can build it from source without > too much trouble, should you need to. If you need to get the fix > through an authorized support channel, well, talk to them. > > - ajax > your errormsg is a bit confusing for me, would you mind to change "link" to "rename" ? something like that ? re, wh ___ 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: Fault reports and bug fixes and expectations
On Mon, 2019-06-17 at 10:31 +, Wheatley, Martin R wrote: > If Oracle will only take the Xorg source rather (as opposed to fixing > it - or even discussing a fix with Xorg - and pushing the fix back to > Xorg) who and when will the issue be fixed so that I can put pressure > on Oracle to generate a patch from the new Xorg code thus improving > the reliability of my control room operation? The X.Org Foundation does not have development resources of its own. Individual and corporate contributors do work on the various components, but usually that work is prioritized by individual or corporate interest. (For example, my employer has very little interest in, say, xcalc, and neither do I, so I tend not to notice issues reported there.) As with many open source projects, patches carry more weight than bug reports. Changing to gitlab has (hopefully) made it significantly easier to submit drive-by fixes for issues like this. To this specific bug: ooh, you can fix this by deletion, my favorite kind of fix. I think this will resolve it: https://gitlab.freedesktop.org/xorg/app/xauth/merge_requests/1 xauth looks like it has a few other minor fixes that have accumulated, I'll be happy to push out a new release once that MR is resolved. I'm not especially familiar with Solaris these days, but xauth itself has changed so little that I suspect you can build it from source without too much trouble, should you need to. If you need to get the fix through an authorized support channel, well, talk to them. - ajax ___ 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: Fault reports and bug fixes and expectations
On 6/17/19 3:31 AM, Wheatley, Martin R wrote: Engineers in our control room really would like the action they request to complete rather than suffer from a random failure (as identified in the bug) so my question is: If Oracle will only take the Xorg source rather (as opposed to fixing it - or even discussing a fix with Xorg - and pushing the fix back to Xorg) Oracle does contribute fixes to Xorg for issues as necessary - but the time we have for that is very limited, and we prioritize issues based on how many people are affected. (And we absolutely prioritize work on Solaris 11.4 over releases in extended support, nearing their end of life, like Solaris 10.) This code in xauth has been in place for 25 years now and it works for millions of users as they only write to their .Xauthority file at the start of the session. (And in modern desktops, they have a separate file per session, set via the XAUTHORITY environment variable, so even in the rare scenarios where they start a second session with the same home directory, they don't clash.) If you are regularly hitting this, I'd ask what you are doing that requires writing to the .Xauthority file so much more often than everyone else in the world. Do you need to write new xauth records so often? Do you even need to write them at all? Why not just use "xhost +si:localuser:" to grant the user access instead of relying on the old shared secret method? who and when will the issue be fixed so that I can put pressure on Oracle to generate a patch from the new Xorg code thus improving the reliability of my control room operation? You are demanding a team of volunteers provide you an exact date for when they'll provide you free help? You're lucky that someone has taken interest in your bug and decided to work on it - many bugs linger for years because there's simply far too few people contributing to X.Org to handle them all, and most of the ones who do contribute have more interesting things to work on. > After all, do you want to be on a plane when the pilot says “we pushed the button to lower the undercarriage – most times the wheels do come down but sometime they might now!”??? If the wheels on a plane fail to lower at landing time, the manufacturer will investigate. If they find that they work reliably on every plane in the fleet where they are only lowered at landing time, and not on the one plane where they are constantly raised and lowered during flight, they are not going to issue a recall and change the landing gear design across the entire fleet, but ask the pilots of that plane to reconsider why they are doing something so unique. -alan- [Absolutely speaking solely for myself, not anyone else.] ___ 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: xorg Digest: Corrupt window
Message: 1 Date: Mon, 17 Jun 2019 15:01:50 -0700 From: Andrew Kurn To: xorg@lists.x.org Subject: Corrupt window Message-ID: <20190617220150.GA2042@Godzilla.local> Content-Type: text/plain; charset=us-ascii I'm using the version of X current for Debian Jessie. I find that windows are sometimes corrupted. The typical case is in XTerm, when the bottom line is covered by a copy of the second-last line. It happens a little more than half the time, so some sort of race condition. It is not confined to XTerm; Emacs and Aisleriot show some of the same behavior. In all cases, moving the window will cure the problem. The redraw is correct. So my conclusion is it's a fault in X. I've never had to report an X bug before. If you will give me a list of info to provide, I will send it in a later message. Otherwise, thanks for your attention. Andrew Your graphics hardware? If you don't know, `lspci -vv` will list everything connected to your PCI bus, but please parse out the graphics info rather than replying with the whole list. Also, on the very unlikely possibility that it's a termcap issue, from an xterm window; what does `echo $TERM` tell you? ___ 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
Can not see mouse pointer
Hello Xorg community, The following happens for a simple GTK based application and also for a simple "-lXaw -lX11 -lXt" linked (athena) application which consists in a small button who exits the application when pressed. I use buildroot and Xorg on raspberry pi to test the app and it works fine when /etc/X11/xinit/xinitrc ends with: /root/athena & exec xterm -geometry 80x50+494+51 But when I remove the last line (the one with exec xterm) and call only "/root/athena" (with or without exec) when I run startx, the mouse pointer is not visible anymore. The athena application appears on the screen but I can not press the button because it is no mouse on the screen. The /var/log/Xorg.0.log after I kill the X server in both cases is: ... [ 749.732] (II) Using input driver 'mouse' for '' [ 749.732] (**) Option "CorePointer" "on" [ 749.732] (**) : always reports core events [ 749.733] (WW) : No Device specified, looking for one... [ 749.800] (II) : Setting Device option to "/dev/input/mice" [ 749.800] (--) : Device: "/dev/input/mice" [ 749.800] (==) : Protocol: "Auto" [ 749.800] (**) : always reports core events [ 749.800] (**) Option "Device" "/dev/input/mice" [ 749.870] (==) : Emulate3Buttons, Emulate3Timeout: 50 [ 749.870] (**) : ZAxisMapping: buttons 4 and 5 [ 749.870] (**) : Buttons: 9 [ 749.871] (II) XINPUT: Adding extended input device "" (type: MOUSE, id 6) [ 749.872] (**) : (accel) keeping acceleration scheme 1 [ 749.872] (**) : (accel) acceleration profile 0 [ 749.872] (**) : (accel) acceleration factor: 2.000 [ 749.872] (**) : (accel) acceleration threshold: 4 [ 749.940] (II) : Setting mouse protocol to "ExplorerPS/2" [ 750.233] (II) : ps2EnableDataReporting: succeeded [ 750.234] (II) Using input driver 'kbd' for '' [ 750.234] (**) Option "CoreKeyboard" "on" [ 750.234] (**) : always reports core events [ 750.234] (**) : always reports core events [ 750.235] (**) Option "Protocol" "standard" [ 750.235] (**) Option "XkbRules" "base" [ 750.235] (**) Option "XkbModel" "pc105" [ 750.235] (**) Option "XkbLayout" "us" [ 750.236] (II) XINPUT: Adding extended input device "" (type: KEYBOARD, id 7) [ 763.139] (II) UnloadModule: "kbd" [ 763.140] (II) UnloadModule: "mouse" [ 763.173] (II) Server terminated successfully (0). Closing log file. Any ideas on how to get mouse on the screen without calling xterm ? Thank you L-C Duca ___ 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: libXt release
On Tue, Jun 18, 2019 at 05:37:40AM -0400, Thomas Dickey wrote: > On Mon, Jun 17, 2019 at 10:08:21AM -0400, Matt Turner wrote: > > On Mon, Jun 17, 2019 at 4:57 AM Thomas Dickey wrote: > > > > > > On Sun, Jun 16, 2019 at 08:08:42PM -0400, Thomas Dickey wrote: > > > > On Thu, Jun 13, 2019 at 03:43:04PM -0400, Thomas Dickey wrote: > > > > > - Original Message - > > > > > | From: "Matt Turner" > > > > > | To: "Thomas Dickey" > > > > > | Cc: "xorg-devel" > > > > > | Sent: Thursday, June 13, 2019 1:47:04 PM > > > > > | Subject: libXt release > > > > > > > > > > | Hi Thomas, > > > > > | > > > > > | I'd like to do a tarball release of libXt since there are now quite > > > > > a > > > > > | few commits since 1.1.5, released in 2015. Are you okay with me > > > > > making > > > > > | a 1.2.0 release now, or is there anything else you would want to get > > > > > | into a new release? > > > > > > > > > > I've been working on some scripts to check for > > > > > breakage in the specification document - might have some fixes there. > > > > > > > > > > I'll review the current state on the weekend, to give better advice. > > > > > > > > I think it's in good shape. Because of the interface change (using > > > > const), I was going to suggest that it should be 1.2.0 > > > > > > I added a merge request for "1.2.0", which I'm testing, > > > should be done tomorrow early (in case someone finds an issue). > > > > Thanks. Are you familiar with the Xorg release scripts [0]? There's a > > wiki page at [1] that has instructions. > > > > If for any reason you have trouble making the release or uploading the > > tarball, let me know and I'll be happy to handle it. > > > > [0] https://gitlab.freedesktop.org/xorg/util/modular/ > > hmm - in a quick check, there's something amiss with the distcheck step > because it's not picking up the right path to the makestrs utility > (or failing to build it in parallel, etc). That's with my Debian/testing > machine. > > I'm investigating that... It looks like some dependency changed, so that makestrs is not automatically built anymore. I'm short of time this morning, will continue this evening. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ 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: libXt release
On Mon, Jun 17, 2019 at 10:08:21AM -0400, Matt Turner wrote: > On Mon, Jun 17, 2019 at 4:57 AM Thomas Dickey wrote: > > > > On Sun, Jun 16, 2019 at 08:08:42PM -0400, Thomas Dickey wrote: > > > On Thu, Jun 13, 2019 at 03:43:04PM -0400, Thomas Dickey wrote: > > > > - Original Message - > > > > | From: "Matt Turner" > > > > | To: "Thomas Dickey" > > > > | Cc: "xorg-devel" > > > > | Sent: Thursday, June 13, 2019 1:47:04 PM > > > > | Subject: libXt release > > > > > > > > | Hi Thomas, > > > > | > > > > | I'd like to do a tarball release of libXt since there are now quite a > > > > | few commits since 1.1.5, released in 2015. Are you okay with me making > > > > | a 1.2.0 release now, or is there anything else you would want to get > > > > | into a new release? > > > > > > > > I've been working on some scripts to check for > > > > breakage in the specification document - might have some fixes there. > > > > > > > > I'll review the current state on the weekend, to give better advice. > > > > > > I think it's in good shape. Because of the interface change (using > > > const), I was going to suggest that it should be 1.2.0 > > > > I added a merge request for "1.2.0", which I'm testing, > > should be done tomorrow early (in case someone finds an issue). > > Thanks. Are you familiar with the Xorg release scripts [0]? There's a > wiki page at [1] that has instructions. > > If for any reason you have trouble making the release or uploading the > tarball, let me know and I'll be happy to handle it. > > [0] https://gitlab.freedesktop.org/xorg/util/modular/ hmm - in a quick check, there's something amiss with the distcheck step because it's not picking up the right path to the makestrs utility (or failing to build it in parallel, etc). That's with my Debian/testing machine. I'm investigating that... Seeing the other mail, I expect some problem uploading the tarball. But that's later :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ 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
