Re: Backward highlight-to-copy misses first characters
One tricky bit relates to pointer resolution, timing, and human hand-eye coordination issues. Also, with some text fonts, it can be hard to see where one letter ends and the next begins. And then there can be pixel roundoff error. At Sun, 3 Nov 2024 14:24:10 -0600 Vasily wrote: > > Carsten, > > Thank you very much for this great answer > I did not know that an application is responsible for providing highlighted > content to copy. > > Regards. > > On 03.11.2024 04:54, Carsten Haitzler wrote: > > On Sat, 2 Nov 2024 17:15:28 -0500 Vasily said: > > > >> Hello > >> > >> Recently I noticed that if highlight a text backward, first couple of > >> characters don't get into the buffer. It can be observed for example in any > >> web browser or text editors. My OS is Ubuntu 22.04 XFCE without Wayland. > >> Any thoughts will be appreciated. > > > > It is each client that is responsible for this, not X itself - highlighting > > is > > a local client issue. all the client does it take ownership of the > > appropriate > > selection. when later you paste - the paste target asks the selection owner > > for > > the data. the owner you highlighted in is responsible for delivering it. > > How it > > was highlighted to begin with is entirely on that end, so I assume you've > > found > > a bug in a toolkit used by the apps above to handle all of this (probably > > GTK). > > > > > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Backward highlight-to-copy misses first characters
It can be 'tricky' to highlight text of a link or text tight up against images. If the application is binding another function to the left mouse button in addition or instead of highlighting, this cn make things hard. At Sun, 3 Nov 2024 14:24:40 -0600 Vasily wrote: > > Vladimir, > > Thank you for your suggestion. > I made a few tests and it looks like there are only few apps that drop first > (and sometime second) character of highlighted text > One of them is chromium (I am not surprised). > Kwrite, LÃÂafpad, Firefox works as expected > > I think this question can be closed. > > Regards > Vasil. > > On 03.11.2024 13:19, Vladimir Dergachev wrote: > > > > I checked on Ubuntu 22.04 with KDE and I do not see the effect with kwrite. > > > > Does kwrite work well for you ? You don't need to switch to KDE window > > manager to use kwrite. > > > > best > > > > Vladimir Dergachev > > > > On Sat, 2 Nov 2024, Vasily wrote: > > > >> Hello > >> > >> Recently I noticed that if highlight a text backward, first couple of > >> characters don't get into the buffer. > >> It can be observed for example in any web browser or text editors. > >> My OS is Ubuntu 22.04 XFCE without Wayland. > >> Any thoughts will be appreciated. > >> > >> Thank you in advance. > >> > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Xorg hotplugging not working for Mouse
At Tue, 26 Jun 2012 11:45:20 +0800 shih dane wrote: > > Hi > i try to modify config > > Option "AutoAddDevices" "True" > > remove all intput device in config > and laod evdev driver > > can not find mouse and keyboad It is not possible to 'hot plug' a PS2 mouse or keyboard under Linux. This is core 'feature' of the hardware / kernel driver. Should work fine for USB mice / keyboards. > > BR > ___ > 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: hel...@deepsoft.com > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 05:45:50 -0300 Fernando Cassia wrote: > > On Sun, Aug 12, 2012 at 5:24 AM, Zhigang Gong > wrote: > > On Sat, Aug 11, 2012 at 10:55:08AM +0200, Paul Menzel wrote: > >> Dear Zhigang, > >> thank you for the announcement message and congratulations on the > >> release. But please do not send HTML messages to lists [1]! > >> Thanks, > >> > >> Paul > >> [1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette > > Hello? OpenSuse? It´s the 21st century, I wanted to tell you guys most > folk have broadband nowadays, so requiring ascii-only email feels a > bit passé. But don´t worry, we´ll take care of the folk still using > dial-up and Eudora Mail 1.0 Most of *rural* America is still on dial-up... > > Kisses! > The 21st century > > *joke* *joke* > ___ > 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: hel...@deepsoft.com > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 10:03:21 -0300 Fernando Cassia wrote: > > > > On Sun, Aug 12, 2012 at 9:09 AM, Robert Heller wrote: > > > Most of *rural* America is still on dial-up... > > > Is it? shame... one would think that some sort of slow-speed DSL would be > possible even on pots lines very very far from the exchange I remember > reading that in Australia Telstra used some ´repeaters´ on the copper lines > allowing DSL to reach distances that were previously thought to be too far > for DSL. Although details about it are a bit foggy on my memory, as I read > about it many years ago. Verizon (the telephone monopoly covering most of the Eastern United States) has no interest in bothering with *any* investment in the copper infrastructure, including installing the DSLAMs needed to bring DSL (even cruddy DSL) to rural America. Also, the copper is old and is falling apart (for lack of1 proper maintainence)-- people actually completely lose basic phone service when it rains. Where DSLAMs has been installed, the signal won't go even the 18,000 feet it should reach, because the copper is below standard. Even what passes for dial-up is pretty bad -- most people can only get a 25Kbps connection, not the 56K we should be getting with modern (V90) modems. > > Needless to say even a 256K always-on ADSL is better thank dial-up > > FC > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 10:13:30 -0300 Fernando Cassia wrote: > > > > On Sun, Aug 12, 2012 at 10:03 AM, Fernando Cassia wrote: > > > Is it? shame... one would think that some sort of slow-speed DSL would be > > possible even on pots lines very very far from the exchange I remember > > reading that in Australia Telstra used some ´repeaters´ on the copper > > lines > > allowing DSL to reach distances that were previously thought to be too far > > for DSL. Although details about it are a bit foggy on my memory, as I read > > about it many years ago. > > > FWIW and not to leave any loose ends in the argument, found it, here´s what > I read about Telstra´s device that could bring DSL even for people up to > 20km away (12 miles) from the phone exchange > http://whirlpool.net.au/news/?id=1432&show=replies OK, this is just a DSLAM. Rural America is not as 'remote' as the Australian Outback. Verizon has plenty of 1st gen DSLAMs (pulled when the denser suburban areas were wired with FIOS), they just are not interested in bothering with rural America, since the customer base is not dense enough to be profitable. > > FC > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 11:12:37 -0400 Gene Heskett wrote: > > On Sunday 12 August 2012 11:04:42 Robert Heller did opine: > [...] > > Verizon (the telephone monopoly covering most of the Eastern United > > States) has no interest in bothering with *any* investment in the > > copper infrastructure, including installing the DSLAMs needed to bring > > DSL (even cruddy DSL) to rural America. Also, the copper is old and is > > falling apart (for lack of1 proper maintainence)-- people actually > > completely lose basic phone service when it rains. > > [...] > > I'll second that, in fact I voted with my wallet 2 years ago when I took > offense at having to call the states PUC on my cell phone just to get my > pots phone working again for the 4th time, in April since Jan 1. Over 90 > of those days I had no pots phone from vz. I've been on cable for both > phone and net for over 2 years now. Verizon didn't have a quarter to call > anyone who cared. Unfortunately for people in my area, Verizon is the *only* game in town: it is either Verizon's crappy (19th century) phone service or no phone service at all. (There is no cable provider and no cell coverage at my house.) > > Cheers, Gene -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 17:34:35 -0400 Gene Heskett wrote: > > On Sunday 12 August 2012 17:33:01 Robert Heller did opine: > > > At Sun, 12 Aug 2012 11:12:37 -0400 Gene Heskett > wrote: > > > On Sunday 12 August 2012 11:04:42 Robert Heller did opine: > > > [...] > > > > > > > Verizon (the telephone monopoly covering most of the Eastern United > > > > States) has no interest in bothering with *any* investment in the > > > > copper infrastructure, including installing the DSLAMs needed to > > > > bring DSL (even cruddy DSL) to rural America. Also, the copper is > > > > old and is falling apart (for lack of1 proper maintainence)-- > > > > people actually completely lose basic phone service when it rains. > > > > > > [...] > > > > > > I'll second that, in fact I voted with my wallet 2 years ago when I > > > took offense at having to call the states PUC on my cell phone just > > > to get my pots phone working again for the 4th time, in April since > > > Jan 1. Over 90 of those days I had no pots phone from vz. I've been > > > on cable for both phone and net for over 2 years now. Verizon didn't > > > have a quarter to call anyone who cared. > > > > Unfortunately for people in my area, Verizon is the *only* game in town: > > it is either Verizon's crappy (19th century) phone service or no phone > > service at all. (There is no cable provider and no cell coverage at my > > house.) > > > > > Cheers, Gene > > Get political. Heckle your states Public Service Commission. There is > always Hughes of course, but they want an arm & a leg per month. Satelite is not an option for me -- too many trees. We are already working on a solution here in Western Mass -- some 40 towns have formed a municipal fiber-to-the-home cooperative -- "Wired West". We figure it will take 2-3 years to get things up and running. > > Cheers, Gene -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)
At Sun, 12 Aug 2012 19:50:02 -0300 Fernando Cassia wrote: > > > > On Sun, Aug 12, 2012 at 10:49 AM, Robert Heller wrote: > > > > > OK, this is just a DSLAM. Rural America is not as 'remote' as the > > Australian Outback. > > > well not exactly... that Australian box is actually a dslam repeater. Are > you saying that even for people who are next door to the phone exchange > that serves you, there is no ADSL offered?. No, just that Western Mass is not as remote as the Australian Outback. By *Australian* standards, yes people 'next door to the phone exchange' (read like 3-10 miles) don't have ADSL. We are not talking about sheep ranches that are 100s of miles in the middle of nowhere. The Australian box appears to be designed for seriously remote places, where a conventual DSLAM is not a viable option. I live about 10 miles from the phone exchange. We are not talking about 30 miles into the desert or anything like that. All Verizon has to do is pour a small concrete pad and plant a conventual DSLAM next to the POTS concentrator that already exists in the center of Wendell and we would have DSL. Verizon has piles of old DSLAMs pulled when they wired the suburbs of Boston with FIOS. > > FC > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Netiquette: No HTML messages please.
At Mon, 13 Aug 2012 09:57:18 +0200 wha...@bfs.de wrote: > > > > Am 12.08.2012 10:45, schrieb Fernando Cassia: > > On Sun, Aug 12, 2012 at 5:24 AM, Zhigang Gong > > wrote: > >> On Sat, Aug 11, 2012 at 10:55:08AM +0200, Paul Menzel wrote: > >>> Dear Zhigang, > >>> thank you for the announcement message and congratulations on the > >>> release. But please do not send HTML messages to lists [1]! > >>> Thanks, > >>> > >>> Paul > >>> [1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette > > > > Hello? OpenSuse? It´s the 21st century, I wanted to tell you guys most > > folk have broadband nowadays, so requiring ascii-only email feels a > > bit passé. But don´t worry, we´ll take care of the folk still using > > dial-up and Eudora Mail 1.0 > > > > > It has nothing todo with broadband, i filter html-mails they can easily > be just to hide spam, so sort them as spam. +1 > > re, > wh > > ___ > 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: hel...@deepsoft.com > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Custom CentOS 5 wont boot into graphical installer
At Fri, 14 Sep 2012 14:18:02 +0200 Eike Kuiper wrote: > > > > Hello everyone, > > i want to make a dvd with custom rpms from a CentOS > 5 in order to install it on my servers. I created this dvd with anaconda > and it worked great, but i have a problem with the graphical installer, > which would not start. in text mode i may install the system, but i have > to configure a raid 1 and lvm and this is not available in text mode. I think you can get around this by using the CLI tools (do a Ctrl-Alt-F2 to get to the shell). > > All graphical packages are recompiled on my system, which has the same > kernel, the servers would have. > > I get following error every time i want to install the server (pasting > it from X.log): > > ... > (II) Module int10: vendor="X.Org foundation" > compiled for 7.1.1, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (II) VESA(0): initializing int10 > (EE) VESA(0): Cannot shmat() low memory > (EE) VESA(0): shmat(low_mem) error: Invalid argument > (II) UnloadModule: "vesa" > (II) UnloadModule: "int10" > ... > > (EE) Sreen(s) found, but none have a usable configuration. > > Fatal server error: > no screens found > > I've tried to change the anaconda version to newest (11.1.2.250-1), > tried to change the xorg-x11-server-Xorg and changed the xorg-x11-drv-* > files. > I also updated all old packages and recompiled them on my system, but i > dont get it work. > > Does anyone have an answer to this? > > Thanks in advance > > infy > > MIME-Version: 1.0 > > ___ > 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: hel...@deepsoft.com > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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
Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
I am the tech guy for a local library. We have a network containing several diskless workstations. The hardware are these P4 boxes: http://www.geeks.com/details.asp?invtid=SAMBA845V-24-4-R&cat=SYS (We have inserted additional memory, bringing most of the machines up to 1.25Gig of memory, and two up to 2Gig of memory.) These little machines have integrated Intel video chips on their motherboards and have both VGA and DVI connectors: (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G (--) I810(0): Chipset: "845G" And the i810 driver seems to be happy to talk to these chips. I am using the stock (distro supplied) RPM: xorg-x11-drv-i810-1.6.5-9.40.el5 The machines are running pretty much stock CentOS 5.8 (I am slightly behind on some updates). These machine boot off the network and then mount their root (/), /usr, and /home file systems via NFS from the server and function otherwise as normal workstations. And they work great with 4:3 monitors. Recently, because of new cataloging and circulation software which seems to have been designed by (open source) developers who probably have new widescreen monitors on their machines, we have put widescreen (16:9) monitors on three of the machines (various menus and toolbars don't fit on a 4:3 monitor, even at 1280x1024 [19-20" monitor]). But we are having some problems getting the proper aspect ratio (or even a display at all) on two of the three. First of all, using the VGA connection, the X server *refuses* to use any Modeline that is not a 4:3 aspect ratio. It seems that the X server presumes that *all* VGA connected monitors are 4:3. (All three of the new wide screen monitors do have 15-pin VGA connections, so this 'presumption' is obviously false, esp. since the monitors using DDC while connection via VGA are suggesting 16:9 mode lines.) I got *one* of the machines to correctly use a 16:9 aspect ratio Modeline (1600x900) using the DVI connection. The other two don't work. One won't display anything (claims that the video is missing or wrong). And the other just uses something like 640x480. Both monitors work just fine on DVI in console display mode (bare kernel VGA), so the video card is seeing the monitor and sending it a signal at that level. I have tried everything I can think of. The various log files and config files are here (each tar file contains one log and one config): This is the *working* machine (HP W2072a): http://www.deepsoft.com/wp-content/uploads/2012/09/catalog-DVI-1600x900.tar.gz These are for a (not working) Acer X223W: http://www.deepsoft.com/wp-content/uploads/2012/09/clearwater-VGA.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/clearwater-DVI.tar.gz >From xdpyinfo while connection via VGA: screen #0: dimensions:1680x1200 pixels (474x302 millimeters) resolution:90x101 dots per inch And for a (not working) ViewSonic VA2431WM: http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-VGA.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI-1600x900.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI-1440x900.tar.gz http://www.deepsoft.com/wp-content/uploads/2012/09/circdesk-DVI.tar.gz >From xdpyinfo while connection via VGA: screen #0: dimensions:1600x1200 pixels (521x290 millimeters) resolution:78x105 dots per inch We would really like square pixels -- is it possible or not? -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Sat, 22 Sep 2012 20:01:49 -0400 Felix Miata wrote: > > On 2012-09-22 17:55 (GMT-0400) Robert Heller composed: > > > I am the tech guy for a local library... > > (II) I810(0): VESA VBE OEM Product: Intel(r)845G/845GL/845GE/845GV Graphics > > Controller > > (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 > > (II) I810(0): Integrated Graphics Chipset: Intel(R) 845G > > (--) I810(0): Chipset: "845G"... > > The 845G has been a troublesome video chip, probably the worst widely used > chip: > https://bugs.freedesktop.org/show_bug.cgi?id=26345 > https://qa.mandriva.com/show_bug.cgi?id=62960 > https://bugzilla.redhat.com/show_bug.cgi?id=692293 > https://bugzilla.novell.com/show_bug.cgi?id=709863 > http://bugs.centos.org/view.php?id=1594 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/930553 > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-driver-nv/+bug/455084 > > Looking through those bugs you might find a clue to a solution. I have two > working 845G systems, but I don't try to use them with non-4:3 displays or > with CentOS, so there's probably little more help I can give given what Adam > Jackson already wrote in thread. > > Most of the 845G systems I've run across include AGP slots. Dell equipped > many of its 845G Optiplex machines with Radeon 7500 AGP cards. There are many > cheap new and used AGP cards around that do support widescreen modes, e.g. > http://www.geeks.com/details.asp?invtid=9250-AGP-128-PB&cat=VCD > http://www.ebay.com/itm/ATI-Technologies-ATI-Radeon-7500-100-711014-64-MB-DDR-SDRAM-AGP-4x-Graphics-/140851713660?pt=PCC_Video_TV_Cards&hash=item20cb6a967c > > http://www.ebay.com/itm/Sapphire-Technology-ATI-Radeon-9250-100582-128-MB-DDR-SDRAM-AGP-8x-Graphics-/140852649792?pt=PCC_Video_TV_Cards&hash=item20cb78df40 > These boxes are small form factor machines and only have two PCI slots on a riser card. No AGP slots, so no option of alternitive video cards, unless with use PCI video cards (are such cards even available?). > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Sat, 22 Sep 2012 18:53:23 -0400 Adam Jackson wrote: > > On 9/22/12 5:55 PM, Robert Heller wrote: > > > First of all, using the VGA connection, the X server *refuses* to use > > any Modeline that is not a 4:3 aspect ratio. It seems that the X > > server presumes that *all* VGA connected monitors are 4:3. (All three > > of the new wide screen monitors do have 15-pin VGA connections, so this > > 'presumption' is obviously false, esp. since the monitors using DDC > > while connection via VGA are suggesting 16:9 mode lines.) > > It's not the X server's fault. > > The i810 driver, when it comes to output setup, is no better than the > vesa driver. It can only set modes that happen to be listed in the > video BIOS, regardless of what the display happens to claim to support. > Since most 845 video BIOSes predate the wide availability of 16:9 > monitors, they naturally tend not to list any 16:9 modes. > > RHEL5 (and therefore CentOS 5) does include an additional video driver > for Intel graphics chips called 'intel' instead of 'i810', which does > not have this limitation. I don't recall offhand whether that version > worked correctly with 8xx-series chips; it might, I don't think I went > out of my way to disable that, but if it doesn't work you get to keep > both pieces. > > Alternatively, go search for 'i915resolution', which will allow you to > override Intel VBIOS mode lists (and yes it does work on 8xx chips > despite the name). I did download and install i915resolution and did patch the Intel VBIOS mode lists, but that didn't help, except for the HP monitor, which does work correctly at 1600x900, but only over the DVI connection, not the VGA connection. I will check and see if I can get the server to use 'intel' driver instead of the i810 driver. > > - ajax > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Sun, 23 Sep 2012 12:21:57 -0400 Felix Miata wrote: > > On 2012-09-23 08:59 (GMT-0400) Alex Deucher composed: > > > The radeon driver does not depend on the the vesa mode list. It can > > natively program just about any mode supported by the monitor. > > This seems to imply the Intel driver does not, and make me wonder why it > doesn't. Which way do the Nouveau and MGA drivers swing? It has been suggested (elsewhere in this thread) that the i810 driver depends on the vesa mode list, but the intel driver does not. My next option will be to change the config files to use the intel driver as opposed to the i810 driver (which is what the original configuration picked automagically). -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Sun, 23 Sep 2012 13:43:54 -0400 Robert Heller wrote: > > At Sun, 23 Sep 2012 12:21:57 -0400 Felix Miata wrote: > > > > > On 2012-09-23 08:59 (GMT-0400) Alex Deucher composed: > > > > > The radeon driver does not depend on the the vesa mode list. It can > > > natively program just about any mode supported by the monitor. > > > > This seems to imply the Intel driver does not, and make me wonder why it > > doesn't. Which way do the Nouveau and MGA drivers swing? > > It has been suggested (elsewhere in this thread) that the i810 driver > depends on the vesa mode list, but the intel driver does not. > > My next option will be to change the config files to use the intel > driver as opposed to the i810 driver (which is what the original > configuration picked automagically). OK, changing the driver from "i810" to "intel" fixes it! I discovered another issue. There seems to be a buffer length problem in the X server: Given that the server looks for its config files in these places (from xorg.conf(5x)): /etc/X11/ /usr/etc/X11/ /etc/X11/$XORGCONFIG /usr/etc/X11/$XORGCONFIG /etc/X11/xorg.conf-4 /etc/X11/xorg.conf /etc/xorg.conf /usr/etc/X11/xorg.conf. /usr/etc/X11/xorg.conf-4 /usr/etc/X11/xorg.conf /usr/lib/X11/xorg.conf. /usr/lib/X11/xorg.conf-4 /usr/lib/X11/xorg.conf If is longer than 33 characers, the server can't locate/open the config file. I'm guessing someone is using a fixed size buffer (#1 nono!) that is not big enough. Yes, some of use use long and meaningful domain and host names... This is the directory containing the xorg config files. For two machines, accounting.wendellfreelibrary.org and clearwater.wendellfreelibrary.org, the Xserver cannot open its config file using the /usr/etc/X11/xorg.conf. pattern. I ended up using the /usr/etc/X11/xorg.conf-4 pattern for both of these machines. server1.wendellfreelibrary.org% dir -1 /usr/etc/X11/ xorg.conf-4@ xorg.conf.accounting.wendellfreelibrary.or xorg.conf.accounting.wendellfreelibrary.org xorg.conf.Acer-DVI.wendellfreelibrary.org xorg.conf.catalog.wendellfreelibrary.org@ xorg.conf.circdesk.wendellfreelibrary.org@ xorg.conf.clearwater@ xorg.conf.clearwater.wendellfreelibrary.or@ xorg.conf.clearwater.wendellfreelibrary.org@ xorg.conf.HPWideScreen.wendellfreelibrary.org xorg.conf.kidsone.wendellfreelibrary.org xorg.conf.kidsone.wendellfreelibrary.org.not xorg.conf.librarian.wendellfreelibrary.org xorg.conf.normalscreen.wendellfreelibrary.org xorg.conf.station1.wendellfreelibrary.org xorg.conf.station2.wendellfreelibrary.org xorg.conf.station3.wendellfreelibrary.org xorg.conf.station5.wendellfreelibrary.org xorg.conf.ViewSonicWS-DVI.wendellfreelibrary.org xorg.conf.ViewSonicWS.wendellfreelibrary.org xorg.conf.widescreen.wendellfreelibrary.org xorg-x11-server-Xorg-1.1.1-48.90.el5 > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Problems with widescreen (16:9) under CentOS 5 w/ xorg-x11-drv-i810-1.6.5-9.40.el5
At Mon, 24 Sep 2012 16:07:26 -0400 Adam Jackson wrote: > > > On Mon, 2012-09-24 at 15:31 -0400, Robert Heller wrote: > > > If is longer than 33 characers, the server can't locate/open > > the config file. I'm guessing someone is using a fixed size buffer (#1 > > nono!) that is not big enough. Yes, some of use use long and meaningful > > domain and host names... > > The hostname buffer is a fixed length anyway, see man gethostname. But > that you're seeing truncation to 33 bytes is certainly a server bug, I > think the MAXHOSTNAMELEN code in hw/xfree86/parser/scan.c should just be > talking about HOST_NAME_MAX like the gethostname man page suggests. Right. HOST_NAME_MAX == 64 on my machine, and allowing for 'xorg.conf.' yields 74 +1 for the NUL byte. The buffer *ought* to be at lease 75 bytes. It *appearently* is only 44 bytes long or something like that, > > - ajax > Content-Description: This is a digitally signed message part > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEABECAAYFAlBgvX4ACgkQW4otUKDs0NNOcgCguvsHTJQwCZS8y8qt3PfIjZzR > UDMAnRmGfiy+CwWMOJy+jvb/HHgZ/fcK > =muxj > -END PGP SIGNATURE- > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: Text Input Box with Xlib
At Sat, 02 Feb 2013 14:02:04 -0800 Alan Coopersmith
wrote:
>
> On 02/ 2/13 01:56 PM, Gabriel Duarte wrote:
> > I already got window and button widgets working, and now I would like
> > to write a text input box, but I have no idea how to start. If someone out
> > there have advices, example code, etc etc, I would be very glad.
>
> The best advice we can give you is to use an existing toolkit.
> Correctly handling all the different languages, writing systems,
> accessibility helpers, etc. is a multi-year project to write, debug,
> and make useful, and one that people have already done for you.
And if you are too impatient for that, just use Tcl/Tk. Tcl is a basic
scripting language that comes with a basic GUI toolkit. One that you
can play with *interactively*. Once you have Tcl/Tk installed (under
Linux it is just a matter of
# Red Hat flavored (RHEL, CentOS, Scientific Linux, Fedora)
yum install tcl tk
# Debian flavored (Debian, Ubuntu, Mint, etc.)
apt-get install tcl tk
), you can do this ('%'=shell prompt):
% wish
pack [entry .e]
and presto, a text input box.
A slightly more exciting example:
% wish
pack [entry .e] -side left
pack [buttom .b \
-text "Hit me" \
-command {puts "You entered: '[.e cget -text]'"}] -side right
The packages *should* come with man pages. Also: visit
http://wiki.tcl.tk/ for lots of fun stuff.
>
--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
___
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: Text Input Box with Xlib
At Sun, 3 Feb 2013 19:35:41 -0200 Gabriel Duarte wrote:
>
>
> Hello!
> No, you didn't get the ideia. I do no want to use a toolkit, I'm writing a
> toolkit. It's an exercise and for fun, not something professional like
> GTK+, Qt or TK. I have already used GTK+ and Qt, even FLTK for my projects,
> so using them is not the big deal. I just asked here for someone who had
> some experience building this kind of stuff and because I'm not so
> experienced to Xlib.
>
> Build a text input box is challenging and because of this I asked for some
> advices of how to write it, not use an already done from some other toolkit.
>
> Thank you anyway :) I will try this week to build some sketch of the text
> input box :)
One thought: The widgets in Tcl/Tk are layered right on top of XLib --
so looking at the source code for Tk might prove very enlightening...
> Cheers
>
> 2013/2/2 Robert Heller
>
> > At Sat, 02 Feb 2013 14:02:04 -0800 Alan Coopersmith <
> > alan.coopersm...@oracle.com> wrote:
> >
> > >
> > > On 02/ 2/13 01:56 PM, Gabriel Duarte wrote:
> > > > I already got window and button widgets working, and now I would like
> > > > to write a text input box, but I have no idea how to start. If someone
> > out
> > > > there have advices, example code, etc etc, I would be very glad.
> > >
> > > The best advice we can give you is to use an existing toolkit.
> > > Correctly handling all the different languages, writing systems,
> > > accessibility helpers, etc. is a multi-year project to write, debug,
> > > and make useful, and one that people have already done for you.
> >
> > And if you are too impatient for that, just use Tcl/Tk. Tcl is a basic
> > scripting language that comes with a basic GUI toolkit. One that you
> > can play with *interactively*. Once you have Tcl/Tk installed (under
> > Linux it is just a matter of
> >
> > # Red Hat flavored (RHEL, CentOS, Scientific Linux, Fedora)
> > yum install tcl tk
> > # Debian flavored (Debian, Ubuntu, Mint, etc.)
> > apt-get install tcl tk
> >
> > ), you can do this ('%'=shell prompt):
> >
> > % wish
> > pack [entry .e]
> >
> > and presto, a text input box.
> >
> > A slightly more exciting example:
> >
> > % wish
> > pack [entry .e] -side left
> > pack [buttom .b \
> > -text "Hit me" \
> > -command {puts "You entered: '[.e cget -text]'"}] -side right
> >
> > The packages *should* come with man pages. Also: visit
> > http://wiki.tcl.tk/ for lots of fun stuff.
> >
> > >
> >
> > --
> > Robert Heller -- 978-544-6933 / hel...@deepsoft.com
> > Deepwoods Software-- http://www.deepsoft.com/
> > () ascii ribbon campaign -- against html e-mail
> > /\ www.asciiribbon.org -- against proprietary attachments
> >
> >
> >
> >
>
>
--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software-- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
___
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: using free desktops without a screen/monitor
At Sun, 28 Apr 2013 15:45:41 -0400 Josh Kennedy wrote: > > Hi > I am totally blind and use gnome, unity lxde and others with the orca > screen reader. I asked on the orca mailing list if there is a way to run > distros such as ubuntu and vinux without a screen or monitor connected. > they said to ask on this list. so I am asking. could you please provide > an accessible way even if its pressing a key at a boot prompt after > hearing some tones through the pc speaker, provide a way to boot and use > ubuntu from the live cd and the installed version without a monitor > being connected. Having this functionality would also enable me to > possibly start a project I have some ideas for using probably sonar > accessible linux with lxde. I *think* that most SVGA video cards will work properly without a monitor connected. I *think* the only problem with starting the X server without a monitor connected would be autodetection of the video modes the monitor can support and I think the default behavior is to assume some 'safe' low-resolution default mode (like 640x480). I think it is possible to come up with a mode setting in xorg.conf that overrides probing for the video modes the monitor supports and 'hardwires' a desired video mode. I don't know what a video card with a digital video will do if there isn't a monitor connected and how the X server will deal with that, but I expect an xorg.conf file can be engineered to create some kind of desired behavior. OTOH, firing up X *without* a monitor would be strange, unless you plan on replacing the normal visual monitor with something else, maybe a video to sonar device or something, in which case this device could behave like a regular monitor and report back a set of video modes it supports, just like a an actual video monitor. The linux system can be configured to not even need a video card, although most PC BIOSs will not work without a video card. Linux itself can be set up to use a serial port (including USB serial ports) for a console. I don't know if that helps you or not. You won't get anything like a 'GUI' type interface (even one adapted for a blind user), but there is no reason not to have a braille based serial TTY type device -- that is some device than converts a serial character stream into braille 'bumps' and some kind of keyboard that sends serial characters back. You would of course be limited to the good old command line interface. It might also be able to have a Speak-And-Spell like device that takes a ASCII character stream and converts that to speech somehow. > > thanks > > Josh > ___ > 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: hel...@deepsoft.com > > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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: X circa 1992
At Sat, 04 May 2013 20:53:37 -0700 Alan Coopersmith wrote: > > On 05/ 3/13 11:20 PM, Geruva Publications wrote: > > Gentlemen, > > > > I am looking at the adaptation of a fairly sizable software package to a > > more > > modern (Linux) environment. The package in it's present state is configured > > to > > use X for graphics, but it appears to date from about 1992. > > > > In some of the release notes, it is stated that for the system will only > > work > > with "variants 31 - 39". Troubling, but I have no idea what this means, but > > one > > of you might. > > Sorry, but I've never heard of such a reference to X like that either. > Are you sure that's not a reference to some aspect of your application? > > > In any event, I would like to have some idea about what would be > > needed to move to contemporary X11. If you could provide some kind of > > guidance > > or starting point for my inquiry, I would be most appreciative. > > I'd suggest just trying to build it. The libX11 library just celebrated 25 > years of maintaining backwards compatibility, and it really hasn't changed > that much - mainly X evolves via adding new extensions to provide new > features. > If you can benefit from some of the new extensions, like Xrender or Xrandr, > you may want to look into them later, but I'd start with just seeing how close > it is to just working now. Some extensions have been dropped over the years, > like PEX & XIE, so ancient applications may hit some roadbumps with those, but > without knowing anything about your application, it's hard to guess what it > may have used. Just to give the OP an idea: xeyes still works, an application that probably *predates* 1992. So does xterm. Probably the *oldest* known X11 application there is. I expect twm is still available, should anyone really want to go there. Yes, the *core* X11 library has been unchanged for a very long time. It is like the wheel -- nobody has really updated the basic shape (round) in *thousands* of years. The OP is more likely to get grumblings from the C compiler, mostly relating to the migration from K&R C to ANSI C and modernizaions of the C library (things should still compile, just all sorts of anoying warnings). The only other issue would be imake (is that still used?) and Motif (but there is OpenMotif). > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments ___ 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
New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
I recently had to replace the monitor on my desktop machine (running CentOS 5.11 w/Xen), but I am having trouble getting a *sane* display resolution. First of all this is an 'older' machine (about 5 years old), with a ASRock K10N78 motherboard with integrated video: VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev a2). I have the stock CentOS 5 Xorg installed: xorg-x11-server-Xorg-1.1.1-48.107.el5.centos xorg-x11-drv-vesa-1.3.0-8.3.el5 XOrg is using the vesa driver, since the NVIDIA GeForce 8200 is not supported by the nv driver (xorg-x11-drv-nv-2.1.15-4.el5). This has been *normally* fine by me -- my old monitor was a 17" 4:3 monitor that worked just fine at 1024x768 resolution. *I* have no need for 3d acceleration. The NVIDIA semi-closed driver is not supported under Xen, so hassling with that is not an option (and if that was the *only* solution, I'll just have to return the monitor to BestBuy and get something else, probably a more expensive 4:3 monitor from Amazon). The new monitor is a NOC model 1970 and it is a 19.5" 16:9 LED monitor. It only has a VGA connection -- DVI or HDMI are not options. I have tried to set suitable mode lines in my xorg.conf file, but Xorg seems to be ignoring them. Why is this? What 'magic' do I need to perform to get Xorg to behave? Right now it is coming up in 1024x768 (which is a 4:3 resolution). I want *square* pixels, so I want a 16:9 display resolution. How do I make that happen? The Xorg log file and my xorg.conf file are available here: http://www.deepsoft.com/wp-content/uploads/2015/12/X11MonitorProbs.zip -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Thu, 03 Dec 2015 16:19:54 +0100 =?iso-8859-1?Q?Thomas_L=FCbking?= wrote: > > VESA defined modes are > - 320Ã200 > - 640Ã400 > - 640Ã480 > - 800Ã600 > - 1024Ã768 > - 1280Ã1024 > > No idea whether the vesa driver supports non-vesa modes, but did you try > using nouveau instead of vesa? What is nouveau? Is that the nv driver? The nv driver does not like the chipset. > > /var/log/Xorg.0.log will tell you the servers opinion on what you added to > your config. > > Cheers, > Thomas > ___ > 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: %(user_address)s > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Thu, 03 Dec 2015 16:19:54 +0100 =?iso-8859-1?Q?Thomas_L=FCbking?= wrote: > > VESA defined modes are > - 320Ã200 > - 640Ã400 > - 640Ã480 > - 800Ã600 > - 1024Ã768 > - 1280Ã1024 > > No idea whether the vesa driver supports non-vesa modes, but did you try > using nouveau instead of vesa? > > /var/log/Xorg.0.log will tell you the servers opinion on what you added to > your config. How do I decipher that opinion? > > Cheers, > Thomas > ___ > 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: %(user_address)s > > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Thu, 03 Dec 2015 20:40:08 +0100 =?iso-8859-1?Q?Thomas_L=FCbking?= wrote: > > On Donnerstag, 3. Dezember 2015 18:42:29 CEST, Robert Heller wrote: > > > How do I decipher that opinion? > > It's cleartext. Not in any useful way. > It should list the modes it considers and whether (and maybe why) it dropped > them. This is what it shows: (II) VESA(0): initializing int10 (II) VESA(0): Primary V_BIOS segment is: 0xc000 (II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 14336 kB (II) VESA(0): VESA VBE OEM: NVIDIA (II) VESA(0): VESA VBE OEM Software Rev: 98.119 (II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation (II) VESA(0): VESA VBE OEM Product: MCP77 Board - mcp78so (II) VESA(0): VESA VBE OEM Product Rev: Chip Rev (++) VESA(0): Depth 24, (--) framebuffer bpp 32 (==) VESA(0): RGB weight 888 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/lib64/xorg/modules/libddc.so (II) Module ddc: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) VESA(0): VESA VBE DDC supported (II) VESA(0): VESA VBE DDC Level 2 (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. (II) VESA(0): VESA VBE DDC read successfully (II) VESA(0): Manufacturer: AOC Model: 1970 Serial#: 83943 (II) VESA(0): Year: 2015 Week: 12 (II) VESA(0): EDID Version: 1.3 (II) VESA(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) VESA(0): Sync: Separate (II) VESA(0): Max Image Size [cm]: horiz.: 41 vert.: 23 (II) VESA(0): Gamma: 2.20 (II) VESA(0): DPMS capabilities: Off; RGB/Color Display (II) VESA(0): First detailed timing is preferred mode (II) VESA(0): redX: 0.641 redY: 0.340 greenX: 0.315 greenY: 0.629 (II) VESA(0): blueX: 0.159 blueY: 0.051 whiteX: 0.313 whiteY: 0.329 (II) VESA(0): Supported VESA Video Modes: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@67Hz (II) VESA(0): 640x480@72Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@56Hz (II) VESA(0): 800x600@60Hz (II) VESA(0): 800x600@72Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 832x624@75Hz (II) VESA(0): 1024x768@60Hz (II) VESA(0): 1024x768@70Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): Manufacturer's mask: 0 (II) VESA(0): Supported Future Video Modes: (II) VESA(0): #0: hsize: 1280 vsize 720 refresh: 60 vid: 49281 (II) VESA(0): Supported additional Video Mode: (II) VESA(0): clock: 85.5 MHz Image Size: 410 x 230 mm (II) VESA(0): h_active: 1366 h_sync: 1436 h_sync_end 1579 h_blank_end 1792 h_border: 0 (II) VESA(0): v_active: 768 v_sync: 771 v_sync_end 774 v_blanking: 798 v_border: 0 (II) VESA(0): Supported additional Video Mode: (II) VESA(0): clock: 85.5 MHz Image Size: 410 x 230 mm (II) VESA(0): h_active: 1360 h_sync: 1424 h_sync_end 1536 h_blank_end 1792 h_border: 0 (II) VESA(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking: 795 v_border: 0 (II) VESA(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 60 kHz, PixClock max 90 MHz (II) VESA(0): Monitor name: 1970W (II) VESA(0): EDID (in hex): (II) VESA(0): 000005e37019e7470100 (II) VESA(0): 0c190103682917782a0cc5a45750a128 (II) VESA(0): 0d5054bfee0081c00101010101010101 (II) VESA(0): 010101010101662156aa51001e30468f (II) VESA(0): 33009ae6101e662150b051001b30 (II) VESA(0): 407036009ae6101e00fd0032 (II) VESA(0): 4c1e3c09000a20202020202000fc (II) VESA(0): 0031393730570a202020202020200018 (II) VESA(0): EDID vendor "AOC", prod id 6512 (II) VESA(0): Using EDID range info for horizontal sync (II) VESA(0): Using EDID range info for vertical refresh (II) VESA(0): Printing DDC gathered Modelines: (II) VESA(0): Modeline "1366x768"x0.0 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync (47.7 kHz) (II) VESA(0): Modeline "1360x768"x0.0 85.50 1360 1424 1536 1792 768 771 777 795 +hsync +vsync (47.7 kHz) (II) VESA(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) VESA(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) VESA(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) VESA(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) VESA(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) VESA(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) VESA(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 131
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Thu, 03 Dec 2015 21:06:57 +0100 =?iso-8859-1?Q?Thomas_L=FCbking?= wrote: > > On Donnerstag, 3. Dezember 2015 20:58:33 CEST, Robert Heller wrote: > > > This is what it shows: > > Can you please attach the entire log? The entire log AND my entire xorg.conf are here: http://www.deepsoft.com/wp-content/uploads/2015/12/X11MonitorProbs.zip Archive: /extra/X11MonitorProbs.zip Length MethodSize Ratio Date Time CRC-32Name -- --- - -- 1812 Defl:N 769 58% 12-03-15 06:21 d0c0c831 xorg.conf 60582 Defl:N 8416 86% 12-02-15 10:46 9613904e Xorg.0.log --- ------ 62394 9185 85%2 files > It sees your added modelines, but discards them (and I assume that is > because of the VESA driver) > > The onlyaccepted modes are > > (**) VESA(0): Built-in mode "1024x768" > > (**) VESA(0): Built-in mode "800x600" > > (**) VESA(0): Built-in mode "640x480" > > So much is for sure. > > > My best suggestion would btw. to try the nouveau driver, but > > > compiled for 7.1.1, module version = 1.0.0 > > ABI class: X.Org Video Driver, version 1.0 > > Are you seriously using Xorg from 2006?? > Any particular reason for doing so? It is what comes with CentOS 5, based on RHEL 5, which RedHat has maintained, complete with backported bug fixes: sauron.deepsoft.com% rpm -q --changelog xorg-x11-drv-vesa|head * Mon Feb 14 2011 Adam Jackson 1.3.0-8.3 - vesa-1.3.1-*.patch: Backport various fixes from upstream, and allow mismatch between 136[0-8]x768 modes. (#614960) - Bump xserver requires to a version that includes VBE PanelID. * Mon Jan 11 2010 Adam Jackson 1.3.0-8.2 - vesa-1.3.0-vbe-dpms.patch: Use VBE's DPMS method, instead of manual VGA register writes, so that laptop backlights turn off too. (#494671) * Mon Jun 04 2007 Adam Jackson 1.3.0-8.1 sauron.deepsoft.com% rpm -q --changelog xorg-x11-server-Xorg | head -30 * Thu Dec 11 2014 Johnny Hughes 1.1.1-48.107.el5.centos - Roll in CentOS Branding * Wed Dec 10 2014 Adam Jackson 1.1.1-48.107 - CVE-2014-8091 denial of service due to unchecked malloc in client authentication (#1168680) - CVE-2014-8092 integer overflow in X11 core protocol requests when calculating memory needs for requests (#1168684) - CVE-2014-8097 out of bounds access due to not validating length or offset values in DBE extension (#1168705) - CVE-2014-8095 out of bounds access due to not validating length or offset values in XInput extension (#1168694) - CVE-2014-8096 out of bounds access due to not validating length or offset values in XC-MISC extension(#1168700) - CVE-2014-8099 out of bounds access due to not validating length or offset values in XVideo extension (#1168710) - CVE-2014-8100 out of bounds access due to not validating length or offset values in Render extension (#1168711) - CVE-2014-8102 out of bounds access due to not validating length or offset values in XFixes extension (#1168714) - CVE-2014-8101 out of bounds access due to not validating length or offset values in RandR extension (#1168713) - CVE-2014-8093 xorg-x11-server: integer overflow in GLX extension requests when calculating memory needs for requests (#1168688) - CVE-2014-8098 xorg-x11-server: out of bounds access due to not validating length or offset values in GLX extension (#1168707) * Tue Mar 25 2014 Adam Jackson 1.1.1-48.104 - xserver-1.1.1-randr-config-timestamps.patch: Backport timestamp comparison fix from upstream RANDR code (#1006076) So, no, it is not really an Xorg from 2006. It just has the same version and API as the Xorg from 2006, bug and security fixes have been backported. I use a distro with long term support. *I* have better things to do than spend all of my time dealing with incompatible updates every few months. > > Cheers, > Thomas > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Thu, 3 Dec 2015 16:27:22 -0500 Felix Miata wrote: > > Robert Heller composed on 2015-12-03 16:00 (UTC-0500): > > > I use a distro with long term support. > > Not without a price. What you have is hardware technology that is more > advanced than the foundation on which that support is built. A GeForce 8200 > needs either the FOSS nouveau driver, which seems to be missing from CentOS > 5, or the proprietary NVidia driver. VESA is a low technology fallback driver > wholly incapable of properly supporting widescreen displays. AFAICT, there's > no amount of xorg.conf or xrandr twiddling you can do to overcome the > shortcomings of a fallback driver. The video chipset has been working fine with the CentOS software, with a 4:3 monitor. The (available) proprietary NVidia driver won't work with a Xen kernel. > > > *I* have better things to do than > > spend all of my time dealing with incompatible updates every few months. > > You have 3 choices that I can see: > > 1-upgrade software to the technology level of your hardware (nouveau driver, > likely requiring KMS kernel) > > 2-backlevel your video hardware (either supported gfxcard, or supported 4:3 > or 5:4 aspect display) > > 3-suffer a standard aspect video mode on your widescreen display -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Fri, 4 Dec 2015 12:32:59 +1000 Dave Airlie wrote: > > On 4 December 2015 at 12:27, Robert Heller wrote: > > At Thu, 3 Dec 2015 16:27:22 -0500 Felix Miata wrote: > > > >> > >> Robert Heller composed on 2015-12-03 16:00 (UTC-0500): > >> > >> > I use a distro with long term support. > >> > >> Not without a price. What you have is hardware technology that is more > >> advanced than the foundation on which that support is built. A GeForce 8200 > >> needs either the FOSS nouveau driver, which seems to be missing from CentOS > >> 5, or the proprietary NVidia driver. VESA is a low technology fallback > >> driver > >> wholly incapable of properly supporting widescreen displays. AFAICT, > >> there's > >> no amount of xorg.conf or xrandr twiddling you can do to overcome the > >> shortcomings of a fallback driver. > > > > The video chipset has been working fine with the CentOS software, with a 4:3 > > monitor. The (available) proprietary NVidia driver won't work with a Xen > > kernel. > > The graphics card BIOS contains the modes that vesa can use. It doesn't have > widescreen modes in it. The below 3 choices are yours. > > CentOS6 should drive things better in theory. I guess I will have to upgade to CentOS 6... > > Dave. > > > >> > >> > *I* have better things to do than > >> > spend all of my time dealing with incompatible updates every few months. > >> > >> You have 3 choices that I can see: > >> > >> 1-upgrade software to the technology level of your hardware (nouveau > >> driver, > >> likely requiring KMS kernel) > >> > >> 2-backlevel your video hardware (either supported gfxcard, or supported 4:3 > >> or 5:4 aspect display) > >> > >> 3-suffer a standard aspect video mode on your widescreen display > > > > -- > > Robert Heller -- 978-544-6933 > > Deepwoods Software-- Custom Software Services > > http://www.deepsoft.com/ -- Linux Administration Services > > hel...@deepsoft.com -- Webhosting Services > > > > ___ > > 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: %(user_address)s > ___ > 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: %(user_address)s > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Fri, 4 Dec 2015 11:42:18 -0500 xorg@lists.x.org wrote: > > If you ready for some fun, CentOS 7 is out and into its third revision. > > Did I miss the discussion about the drivers from NVIDIA? I am using them > with new and old hardware(different machines). > A bit tricky to get working and there are different drivers for legacy > cards and newer cards. The drivers from NVIDIA are not supported for Xen-based systems. I am using Xen for virtualization, so the drivers from NVIDIA are not an option. Appearently the kernel and Xorg that sh > > I had trouble with the nouveau driver but it may have been me or may > have been an early version. The nouveau driver is not available for CentOS 5 -- the kernel and Xorg libraries are too old. > > CentOS 7 runs well but it does have a lot of changes to the tools that > one got used to in CentOS 5 and 6. *I* am not ready for that big a change. It would probably be too disruptive for my work flow. I *may* install CentOS 7 as a VM at some point. > It is supposed to be a better workstation OS. > > I am still running 5 and 6 on some production machines. > I am not using my units as workstations but like to have the GUI working > well in case I have some maintenance activities that are easier in the GUI. > > Ron > > On 04/12/2015 10:30 AM, Robert Heller wrote: > > At Fri, 4 Dec 2015 12:32:59 +1000 Dave Airlie wrote: > > > >> On 4 December 2015 at 12:27, Robert Heller wrote: > >>> At Thu, 3 Dec 2015 16:27:22 -0500 Felix Miata > >>> wrote: > >>> > >>>> Robert Heller composed on 2015-12-03 16:00 (UTC-0500): > >>>> > >>>>> I use a distro with long term support. > >>>> Not without a price. What you have is hardware technology that is more > >>>> advanced than the foundation on which that support is built. A GeForce > >>>> 8200 > >>>> needs either the FOSS nouveau driver, which seems to be missing from > >>>> CentOS > >>>> 5, or the proprietary NVidia driver. VESA is a low technology fallback > >>>> driver > >>>> wholly incapable of properly supporting widescreen displays. AFAICT, > >>>> there's > >>>> no amount of xorg.conf or xrandr twiddling you can do to overcome the > >>>> shortcomings of a fallback driver. > >>> The video chipset has been working fine with the CentOS software, with a > >>> 4:3 > >>> monitor. The (available) proprietary NVidia driver won't work with a Xen > >>> kernel. > >> The graphics card BIOS contains the modes that vesa can use. It doesn't > >> have > >> widescreen modes in it. The below 3 choices are yours. > >> > >> CentOS6 should drive things better in theory. > > I guess I will have to upgade to CentOS 6... > > > >> Dave. > >>>>> *I* have better things to do than > >>>>> spend all of my time dealing with incompatible updates every few months. > >>>> You have 3 choices that I can see: > >>>> > >>>> 1-upgrade software to the technology level of your hardware (nouveau > >>>> driver, > >>>> likely requiring KMS kernel) > >>>> > >>>> 2-backlevel your video hardware (either supported gfxcard, or supported > >>>> 4:3 > >>>> or 5:4 aspect display) > >>>> > >>>> 3-suffer a standard aspect video mode on your widescreen display > >>> -- > >>> Robert Heller -- 978-544-6933 > >>> Deepwoods Software-- Custom Software Services > >>> http://www.deepsoft.com/ -- Linux Administration Services > >>> hel...@deepsoft.com -- Webhosting Services > >>> > >>> ___ > >>> 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: %(user_address)s > >> ___ > >> 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: %(user_address)s > >> > >> > >> > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: %(user_address)s
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Fri, 4 Dec 2015 15:11:33 -0500 xorg@lists.x.org wrote: > > I am just using the KVM included in CentOS7 with Cloudstack. > Not sure what I am missing by not including Xen but I am pretty new at it. CentOS 5 predates KVM and used Xen for virtualization. CentOS 6 and 7 include KVM for virtualization and don't use a Xen hypervisor. You are not 'missing' anything: Xen is just the older virtualization hypervisor. > > I can not help but believe that CentOS 7 would be a better platform for > virtualization than CentOS 5. > > CentOS 7 is not too bad but it is different and it has taken me a while > to stop fighting it. I don't want to take that step until I have learned to deal with the likes of systemd, etc. I install CentOS 6 as the host and install CentOS 7 in a VM, to have a standbox to learn in, and still be able to get work done. > The changes to networking and the firewall were hard to absorb. The new > way to manage processes is still a bit of a challenge for me but I am > not spending any time on this since it works just fine. > > I run a software firewall, DNS server and virtual router which I moved > from CentOS 4 to CentOS 7 and it seems to work better but it is hard to > tell if it is the newer hardware or the new OS. This is a critical part > of the infrastructure and I am happy with the change. > The hardware was too old to run the nouveau driver properly so I am > running the NVIDIA legacy driver. Works but I am not using it as a > workstation. > > > Ron > > On 04/12/2015 12:43 PM, Robert Heller wrote: > > At Fri, 4 Dec 2015 11:42:18 -0500 xorg@lists.x.org wrote: > > > >> If you ready for some fun, CentOS 7 is out and into its third revision. > >> > >> Did I miss the discussion about the drivers from NVIDIA? I am using them > >> with new and old hardware(different machines). > >> A bit tricky to get working and there are different drivers for legacy > >> cards and newer cards. > > The drivers from NVIDIA are not supported for Xen-based systems. I am using > > Xen for virtualization, so the drivers from NVIDIA are not an option. > > Appearently the kernel and Xorg that sh > > > >> I had trouble with the nouveau driver but it may have been me or may > >> have been an early version. > > The nouveau driver is not available for CentOS 5 -- the kernel and Xorg > > libraries are too old. > > > >> CentOS 7 runs well but it does have a lot of changes to the tools that > >> one got used to in CentOS 5 and 6. > > *I* am not ready for that big a change. It would probably be too disruptive > > for my work flow. I *may* install CentOS 7 as a VM at some point. > > > >> It is supposed to be a better workstation OS. > >> > >> I am still running 5 and 6 on some production machines. > >> I am not using my units as workstations but like to have the GUI working > >> well in case I have some maintenance activities that are easier in the GUI. > >> > >> Ron > >> > >> On 04/12/2015 10:30 AM, Robert Heller wrote: > >>> At Fri, 4 Dec 2015 12:32:59 +1000 Dave Airlie wrote: > >>> > >>>> On 4 December 2015 at 12:27, Robert Heller wrote: > >>>>> At Thu, 3 Dec 2015 16:27:22 -0500 Felix Miata > >>>>> wrote: > >>>>> > >>>>>> Robert Heller composed on 2015-12-03 16:00 (UTC-0500): > >>>>>> > >>>>>>> I use a distro with long term support. > >>>>>> Not without a price. What you have is hardware technology that is more > >>>>>> advanced than the foundation on which that support is built. A GeForce > >>>>>> 8200 > >>>>>> needs either the FOSS nouveau driver, which seems to be missing from > >>>>>> CentOS > >>>>>> 5, or the proprietary NVidia driver. VESA is a low technology fallback > >>>>>> driver > >>>>>> wholly incapable of properly supporting widescreen displays. AFAICT, > >>>>>> there's > >>>>>> no amount of xorg.conf or xrandr twiddling you can do to overcome the > >>>>>> shortcomings of a fallback driver. > >>>>> The video chipset has been working fine with the CentOS software, with > >>>>> a 4:3 > >>>>> monitor. The (available) proprietary NVidia driver won't work with a Xen > >>>>> kernel. > >>>> The graphics card BIOS contains the modes that vesa can use. It doesn't
Re: New Monitor Weirdnesses or how do I get Xorg to pay attention to my xorg.conf file?
At Sat, 5 Dec 2015 21:48:17 -0500 xorg@lists.x.org wrote: > > On 04/12/2015 9:06 PM, Robert Heller wrote: > > At Fri, 4 Dec 2015 15:11:33 -0500 xorg@lists.x.org wrote: > > > >> I am just using the KVM included in CentOS7 with Cloudstack. > >> Not sure what I am missing by not including Xen but I am pretty new at it. > > CentOS 5 predates KVM and used Xen for virtualization. CentOS 6 and 7 > > include > > KVM for virtualization and don't use a Xen hypervisor. You are not 'missing' > > anything: Xen is just the older virtualization hypervisor. > That is what I suspected. Thanks to the reassurance. > > > >> I can not help but believe that CentOS 7 would be a better platform for > >> virtualization than CentOS 5. > >> > >> CentOS 7 is not too bad but it is different and it has taken me a while > >> to stop fighting it. > > I don't want to take that step until I have learned to deal with the likes > > of > > systemd, etc. I install CentOS 6 as the host and install CentOS 7 in a VM, > > to > > have a standbox to learn in, and still be able to get work done. > Sounds like a good plan. > I just jumped in with a couple of spare physical machines to see if I > could get Centos 7 to production quality/use in key roles. I don't have the spare hardware and cannot at this time afford to buy it. > I was able to build the systems and test them with the ability to drop > the old system back in if it did not work. I will be installing C6 on a 'spare' logical volume and leave the existing C5 system in place, creating a 'dual boot' system. I've done this before with the previous times I have migrated. I'll just be doing this much sooner than I had originally planned. > > >> The changes to networking and the firewall were hard to absorb. The new > >> way to manage processes is still a bit of a challenge for me but I am > >> not spending any time on this since it works just fine. > >> > >> I run a software firewall, DNS server and virtual router which I moved > >> from CentOS 4 to CentOS 7 and it seems to work better but it is hard to > >> tell if it is the newer hardware or the new OS. This is a critical part > >> of the infrastructure and I am happy with the change. > >> The hardware was too old to run the nouveau driver properly so I am > >> running the NVIDIA legacy driver. Works but I am not using it as a > >> workstation. > >> > >> > >> Ron > >> > >>On 04/12/2015 12:43 PM, Robert Heller wrote: > >>> At Fri, 4 Dec 2015 11:42:18 -0500 xorg@lists.x.org wrote: > >>> > >>>> If you ready for some fun, CentOS 7 is out and into its third revision. > >>>> > >>>> Did I miss the discussion about the drivers from NVIDIA? I am using them > >>>> with new and old hardware(different machines). > >>>> A bit tricky to get working and there are different drivers for legacy > >>>> cards and newer cards. > >>> The drivers from NVIDIA are not supported for Xen-based systems. I am > >>> using > >>> Xen for virtualization, so the drivers from NVIDIA are not an option. > >>> Appearently the kernel and Xorg that sh > >>> > >>>> I had trouble with the nouveau driver but it may have been me or may > >>>> have been an early version. > >>> The nouveau driver is not available for CentOS 5 -- the kernel and Xorg > >>> libraries are too old. > >>> > >>>> CentOS 7 runs well but it does have a lot of changes to the tools that > >>>> one got used to in CentOS 5 and 6. > >>> *I* am not ready for that big a change. It would probably be too > >>> disruptive > >>> for my work flow. I *may* install CentOS 7 as a VM at some point. > >>> > >>>> It is supposed to be a better workstation OS. > >>>> > >>>> I am still running 5 and 6 on some production machines. > >>>> I am not using my units as workstations but like to have the GUI working > >>>> well in case I have some maintenance activities that are easier in the > >>>> GUI. > >>>> > >>>> Ron > >>>> > >>>> On 04/12/2015 10:30 AM, Robert Heller wrote: > >>>>> At Fri, 4 Dec 2015 12:32:59 +1000 Dave Airlie wrote: > >>>>> > >>>>>> On 4 December 2015 at 12:27, Robert Heller wrote: > >>>>>>> At T
X11 Xserver startup problem on a Raspberry PI
59323.624] (**) HID 04d9:a088: Applying InputClass "libinput keyboard catchall" [159323.624] (II) LoadModule: "libinput" [159323.625] (II) Loading /usr/lib/xorg/modules/input/libinput_drv.so [159323.634] (II) Module libinput: vendor="X.Org Foundation" [159323.634]compiled for 1.18.4, module version = 0.20.0 [159323.634]Module class: X.Org XInput Driver [159323.634]ABI class: X.Org XInput driver, version 22.1 [159323.636] (II) systemd-logind: got fd for /dev/input/event0 13:64 fd 11 paused 0 [159323.637] (II) Using input driver 'libinput' for 'HID 04d9:a088' [159323.637] (**) HID 04d9:a088: always reports core events [159323.637] (**) Option "Device" "/dev/input/event0" [159323.637] (**) Option "_source" "server/udev" [159323.639] (II) input device 'HID 04d9:a088', /dev/input/event0 is tagged by udev as: Keyboard [159323.640] (II) input device 'HID 04d9:a088', /dev/input/event0 is a keyboard [159323.640] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f98.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.0/0003:04D9:A088.0001/input/input0/event0" [159323.640] (II) XINPUT: Adding extended input device "HID 04d9:a088" (type: KEYBOARD, id 6) [159323.641] (**) Option "xkb_model" "pc105" [159323.641] (**) Option "xkb_layout" "gb" [159323.754] (II) input device 'HID 04d9:a088', /dev/input/event0 is tagged by udev as: Keyboard [159323.754] (II) input device 'HID 04d9:a088', /dev/input/event0 is a keyboard [159323.757] (II) config/udev: Adding input device HID 04d9:a088 (/dev/input/event1) [159323.757] (**) HID 04d9:a088: Applying InputClass "libinput pointer catchall" [159323.757] (**) HID 04d9:a088: Applying InputClass "libinput keyboard catchall" [159323.760] (II) systemd-logind: got fd for /dev/input/event1 13:65 fd 14 paused 0 [159323.760] (II) Using input driver 'libinput' for 'HID 04d9:a088' [159323.760] (**) HID 04d9:a088: always reports core events [159323.760] (**) Option "Device" "/dev/input/event1" [159323.760] (**) Option "_source" "server/udev" [159323.762] (II) input device 'HID 04d9:a088', /dev/input/event1 is tagged by udev as: Keyboard Mouse [159323.762] (II) input device 'HID 04d9:a088', /dev/input/event1 is a pointer caps [159323.762] (II) input device 'HID 04d9:a088', /dev/input/event1 is a keyboard [159323.763] (II) libinput: HID 04d9:a088: needs a virtual subdevice [159323.763] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f98.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.1/0003:04D9:A088.0002/input/input1/event1" [159323.763] (II) XINPUT: Adding extended input device "HID 04d9:a088" (type: MOUSE, id 7) [159323.764] (**) Option "AccelerationScheme" "none" [159323.764] (**) HID 04d9:a088: (accel) selected scheme none/0 [159323.764] (**) HID 04d9:a088: (accel) acceleration factor: 2.000 [159323.764] (**) HID 04d9:a088: (accel) acceleration threshold: 4 [159323.766] (II) input device 'HID 04d9:a088', /dev/input/event1 is tagged by udev as: Keyboard Mouse [159323.766] (II) input device 'HID 04d9:a088', /dev/input/event1 is a pointer caps [159323.766] (II) input device 'HID 04d9:a088', /dev/input/event1 is a keyboard [159323.768] (II) config/udev: Adding input device HID 04d9:a088 (/dev/input/mouse0) [159323.768] (II) No input driver specified, ignoring this device. [159323.768] (II) This device may have been added with another device file. [159323.787] (**) HID 04d9:a088: Applying InputClass "libinput pointer catchall" [159323.787] (**) HID 04d9:a088: Applying InputClass "libinput keyboard catchall" [159323.787] (II) systemd-logind: returning pre-existing fd for /dev/input/event1 13:65 [159323.787] (II) Using input driver 'libinput' for 'HID 04d9:a088' [159323.787] (**) HID 04d9:a088: always reports core events [159323.787] (**) Option "Device" "/dev/input/event1" [159323.787] (**) Option "_source" "_driver/libinput" [159323.788] (II) libinput: HID 04d9:a088: is a virtual subdevice [159323.788] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f98.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.1/0003:04D9:A088.0002/input/input1/event1" [159323.788] (II) XINPUT: Adding extended input device "HID 04d9:a088" (type: KEYBOARD, id 8) [159323.788] (**) Option "xkb_model" "pc105" [159323.788] (**) Option "xkb_layout" "gb" [159324.195] (**) Option "fd" "11" [159324.196] (**) Option "fd" "14" [159324.197] (**) Option "fd" "14" [159324.201] (II) UnloadModule: "libinput" [159324.201] (II) systemd-logind: not releasing fd for 13:65, still in use [159324.202] (II) UnloadModule: "libinput" [159324.202] (II) systemd-logind: releasing fd for 13:65 [159324.240] (II) UnloadModule: "libinput" [159324.241] (II) systemd-logind: releasing fd for 13:64 [159324.313] (II) Server terminated successfully (0). Closing log file. Is there something I need to do to fix this? Some magic to add to the conf.d directory? -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: X11 Xserver startup problem on a Raspberry PI
At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer wrote: > > On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote: > > I have a Raspberry Pi (Model 2 B) running a fairly recent version of > > Raspbian > > (2017-04-10-raspbian-jessie.zip). I have it start up to the console login, > > since most of the time I just ssh into it from another machine (either my > > CentOS laptop or desktop). I just tied to login into its console (using my > > TV > > as a monitor) and using the startx command t fire up the GUI, but it is > > failing. I *think* it is having some sort of problem with the input device > > I > > am using: a combo keyboard / trackball: > > there are no error messages in the log regarding libinput, it all comes up > normally. So whatever the issue is, I don't think that's it. the logind > messages looked fine too, so that shouldn't be an issue either. > > fwiw, you could easily verify it with sudo libinput-debug-events, if that > handles the events correctly then the driver will too and you can mostly > rule out libinput issues. Well, libinput-debug-events does not seem to be installed... What package would it be in? dpkg-query -l \*libinput\* yields: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---=== ii libinput-bin1.5.0-1 armhfinput device management and event handling library - udev quirks ii libinput10:armhf1.5.0-1 armhfinput device management and event handling library - shared library ii xserver-xorg-input-libinput 0.20.0-1 armhfX.Org X server -- libinput input driver > > "it is failing" is a bit generic, what exactly doesn't work? The XServer does not start -- I type startx, and after a brief startup blather and a brief screen blanking, it lands back at the shell prompt. The log file is all I have. Yes, it appears that XServer sees everything, but for some reason just exits after it has finished probing... No "obvious" (to me) reason (I have seen Xservers die for various reasons, like bad video timing rates on unsupported video chips, or totally missing mice and/or keyboards -- mostly in the "bad old days" where one had to set things up properly in /etc/X11/xorg.conf. I believe these days, one does not bother with hand-crafter conf files -- the XServer figures itself out "on the fly". (Or not as the case might be...) > > Cheers, >Peter > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: X11 Xserver startup problem on a Raspberry PI
At Robert Heller wrote: > > At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer > wrote: > > > > > On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote: > > > I have a Raspberry Pi (Model 2 B) running a fairly recent version of > > > Raspbian > > > (2017-04-10-raspbian-jessie.zip). I have it start up to the console > > > login, > > > since most of the time I just ssh into it from another machine (either my > > > CentOS laptop or desktop). I just tied to login into its console (using > > > my TV > > > as a monitor) and using the startx command t fire up the GUI, but it is > > > failing. I *think* it is having some sort of problem with the input > > > device I > > > am using: a combo keyboard / trackball: > > > > there are no error messages in the log regarding libinput, it all comes up > > normally. So whatever the issue is, I don't think that's it. the logind > > messages looked fine too, so that shouldn't be an issue either. > > > > fwiw, you could easily verify it with sudo libinput-debug-events, if that > > handles the events correctly then the driver will too and you can mostly > > rule out libinput issues. > > Well, libinput-debug-events does not seem to be installed... What package > would it be in? dpkg-query -l \*libinput\* yields: > > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ NameVersion Architecture Description > +++-===---=== > ii libinput-bin1.5.0-1 armhfinput device > management and event handling library - udev quirks > ii libinput10:armhf1.5.0-1 armhfinput device > management and event handling library - shared library > ii xserver-xorg-input-libinput 0.20.0-1 armhfX.Org X server -- > libinput input driver > > > > > "it is failing" is a bit generic, what exactly doesn't work? > > The XServer does not start -- I type startx, and after a brief startup blather > and a brief screen blanking, it lands back at the shell prompt. The log file > is all I have. Yes, it appears that XServer sees everything, but for some > reason just exits after it has finished probing... No "obvious" (to me) reason > (I have seen Xservers die for various reasons, like bad video timing rates on > unsupported video chips, or totally missing mice and/or keyboards -- mostly in > the "bad old days" where one had to set things up properly in > /etc/X11/xorg.conf. I believe these days, one does not bother with > hand-crafter conf files -- the XServer figures itself out "on the fly". (Or > not as the case might be...) OK, another datapoint: *I* don't use the "pi" account on my pis -- I create an account "heller" so make things consistent with my other Linux boxes (an x86_64 home built desktop and a x86_64 Lenovo Thinkpad laptop). When I log into the 'Pi as "pi", startx works. It does not work when I log in as heller. This is *weird* (at least from this long time Linux user). > > > > > Cheers, > >Peter > > > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: X11 Xserver startup problem on a Raspberry PI
At Robert Heller wrote: > > At Robert Heller wrote: > > > > > At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer > > wrote: > > > > > > > > On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote: > > > > I have a Raspberry Pi (Model 2 B) running a fairly recent version of > > > > Raspbian > > > > (2017-04-10-raspbian-jessie.zip). I have it start up to the console > > > > login, > > > > since most of the time I just ssh into it from another machine (either > > > > my > > > > CentOS laptop or desktop). I just tied to login into its console > > > > (using my TV > > > > as a monitor) and using the startx command t fire up the GUI, but it is > > > > failing. I *think* it is having some sort of problem with the input > > > > device I > > > > am using: a combo keyboard / trackball: > > > > > > there are no error messages in the log regarding libinput, it all comes up > > > normally. So whatever the issue is, I don't think that's it. the logind > > > messages looked fine too, so that shouldn't be an issue either. > > > > > > fwiw, you could easily verify it with sudo libinput-debug-events, if that > > > handles the events correctly then the driver will too and you can mostly > > > rule out libinput issues. > > > > Well, libinput-debug-events does not seem to be installed... What package > > would it be in? dpkg-query -l \*libinput\* yields: > > > > Desired=Unknown/Install/Remove/Purge/Hold > > | > > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > > ||/ NameVersion Architecture Description > > +++-===---=== > > ii libinput-bin1.5.0-1 armhfinput device > > management and event handling library - udev quirks > > ii libinput10:armhf1.5.0-1 armhfinput device > > management and event handling library - shared library > > ii xserver-xorg-input-libinput 0.20.0-1 armhfX.Org X server -- > > libinput input driver > > > > > > > > "it is failing" is a bit generic, what exactly doesn't work? > > > > The XServer does not start -- I type startx, and after a brief startup > > blather > > and a brief screen blanking, it lands back at the shell prompt. The log file > > is all I have. Yes, it appears that XServer sees everything, but for some > > reason just exits after it has finished probing... No "obvious" (to me) > > reason > > (I have seen Xservers die for various reasons, like bad video timing rates > > on > > unsupported video chips, or totally missing mice and/or keyboards -- mostly > > in > > the "bad old days" where one had to set things up properly in > > /etc/X11/xorg.conf. I believe these days, one does not bother with > > hand-crafter conf files -- the XServer figures itself out "on the fly". (Or > > not as the case might be...) > > OK, another datapoint: > > *I* don't use the "pi" account on my pis -- I create an account "heller" so > make things consistent with my other Linux boxes (an x86_64 home built > desktop > and a x86_64 Lenovo Thinkpad laptop). > > When I log into the 'Pi as "pi", startx works. It does not work when I log > in > as heller. This is *weird* (at least from this long time Linux user). > OK, problem solved: it was a bad .xsession file. It has been so long since I needed to troubleshoot a .xsession that I had forgotten to check there. > > > > > > > > Cheers, > > >Peter > > > > > > > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: X11 Xserver startup problem on a Raspberry PI
At Tue, 27 Jun 2017 09:22:37 +0200 wha...@bfs.de wrote: > > > > Am 27.06.2017 03:03, schrieb Robert Heller: > > At Robert Heller wrote: > > > >> > >> At Robert Heller wrote: > >> > >>> > >>> At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer > >>> wrote: > >>> > >>>> > >>>> On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote: > >>>>> I have a Raspberry Pi (Model 2 B) running a fairly recent version of > >>>>> Raspbian > >>>>> (2017-04-10-raspbian-jessie.zip). I have it start up to the console > >>>>> login, > >>>>> since most of the time I just ssh into it from another machine (either > >>>>> my > >>>>> CentOS laptop or desktop). I just tied to login into its console > >>>>> (using my TV > >>>>> as a monitor) and using the startx command t fire up the GUI, but it is > >>>>> failing. I *think* it is having some sort of problem with the input > >>>>> device I > >>>>> am using: a combo keyboard / trackball: > >>>> > >>>> there are no error messages in the log regarding libinput, it all comes > >>>> up > >>>> normally. So whatever the issue is, I don't think that's it. the logind > >>>> messages looked fine too, so that shouldn't be an issue either. > >>>> > >>>> fwiw, you could easily verify it with sudo libinput-debug-events, if that > >>>> handles the events correctly then the driver will too and you can mostly > >>>> rule out libinput issues. > >>> > >>> Well, libinput-debug-events does not seem to be installed... What > >>> package > >>> would it be in? dpkg-query -l \*libinput\* yields: > >>> > >>> Desired=Unknown/Install/Remove/Purge/Hold > >>> | > >>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > >>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > >>> ||/ NameVersion Architecture Description > >>> +++-===---=== > >>> ii libinput-bin1.5.0-1 armhfinput device > >>> management and event handling library - udev quirks > >>> ii libinput10:armhf1.5.0-1 armhfinput device > >>> management and event handling library - shared library > >>> ii xserver-xorg-input-libinput 0.20.0-1 armhfX.Org X server > >>> -- libinput input driver > >>> > >>>> > >>>> "it is failing" is a bit generic, what exactly doesn't work? > >>> > >>> The XServer does not start -- I type startx, and after a brief startup > >>> blather > >>> and a brief screen blanking, it lands back at the shell prompt. The log > >>> file > >>> is all I have. Yes, it appears that XServer sees everything, but for some > >>> reason just exits after it has finished probing... No "obvious" (to me) > >>> reason > >>> (I have seen Xservers die for various reasons, like bad video timing > >>> rates on > >>> unsupported video chips, or totally missing mice and/or keyboards -- > >>> mostly in > >>> the "bad old days" where one had to set things up properly in > >>> /etc/X11/xorg.conf. I believe these days, one does not bother with > >>> hand-crafter conf files -- the XServer figures itself out "on the fly". > >>> (Or > >>> not as the case might be...) > >> > >> OK, another datapoint: > >> > >> *I* don't use the "pi" account on my pis -- I create an account "heller" > >> so > >> make things consistent with my other Linux boxes (an x86_64 home built > >> desktop > >> and a x86_64 Lenovo Thinkpad laptop). > >> > >> When I log into the 'Pi as "pi", startx works. It does not work when I > >> log in > >> as heller. This is *weird* (at least from this long time Linux user). > >> > > > > OK, problem solved: it was a bad .xsession file. It has been so long since
Middle button emulation...
I can't seem to find the option/setting magic to get middle button emulation enabled and working. This is on a Raspberry Pi (Raspbian with xserver-xorg-input-all 1:7.7+16 and xserver-xorg-input-libinput 0.20.0-1). I have a keyboard/trackball combo device and it only has two buttons. I have been using (proper) three button pointer devices on all of my other machines and I really need that middle button. I'm not seeing anything in any of the man pages. Has middle button emulation been dropped? (Where have all the hard core / old school UNIX hackers gone? Am I the only one left?) -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Re: Middle button emulation...
At Sat, 01 Jul 2017 15:16:32 +0200 "Ralf Mattes" wrote: > > > Am Samstag, 01. Juli 2017 15:00 CEST, "Ralf Mattes" = > schrieb: > > > > [...]> > > You could put something loike that (most likely you dont' have a PS/2= > mouse :-) > > into /usr/share/X11/xorg.conf.d/my-mouse.conf > > If you don't want to wite a configutation file you can also do this wit= > h xinput: > > # Find your pointing device > xinput list > > # find all configurable options of that device > xinput list-props > > # switch in middle button emulation > xinput set-prop "Evdev Middle Button Emulation" 1 > > HTH, Ralf Mattes The prop name was different, but this worked. I could not figure out what to say for "Option" in the config file. so I gave up on that. There is some serious lack of documentation here. Or else there does not seem to be any way to specify this in the confguration files. I wonder if I should file a bug report somewhere (is there a bugzilla.xorg.org or something like that?). > > > > > > > > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Re: Middle button emulation...
At Mon, 3 Jul 2017 13:04:37 +1000 Peter Hutterer wrote: > > On Sat, Jul 01, 2017 at 06:48:50PM -0400, Robert Heller wrote: > > At Sat, 01 Jul 2017 15:16:32 +0200 "Ralf Mattes" > > wrote: > > > > > > > > > > > Am Samstag, 01. Juli 2017 15:00 CEST, "Ralf Mattes" = > > > schrieb: > > > > > > > > > > [...]> > > > > You could put something loike that (most likely you dont' have a PS/2= > > > mouse :-) > > > > into /usr/share/X11/xorg.conf.d/my-mouse.conf > > > > > > If you don't want to wite a configutation file you can also do this wit= > > > h xinput: > > > > > > # Find your pointing device > > > xinput list > > > > > > # find all configurable options of that device > > > xinput list-props > > > > > > # switch in middle button emulation > > > xinput set-prop "Evdev Middle Button Emulation" 1 > > fwiw, you can use the device name in quotes instead of the device id. > > > > HTH, Ralf Mattes > > > > The prop name was different, but this worked. I could not figure out what > > to > > say for "Option" in the config file. so I gave up on that. > > If you're using the libinput driver, you need to use the libinput-specific > property - which is prefixed with 'libinput' instead of 'Evdev'. So I > suspect you changed "libinput Middle Emulation Enabled" > > > There is some serious lack of documentation here. > > both the property and the option are documented in the driver's man page, > man 4 libinput Ah. But there is not link between man 5 xorg.conf and man 4 libinput... So I guess there is a documentation bug of sorts... > > > > Or else there does not seem > > to be any way to specify this in the confguration files. I wonder if I > > should > > file a bug report somewhere (is there a bugzilla.xorg.org or something like > > that?). > > bugs.freedesktop.org is our bugzilla, for next time. > > > Cheers, >Peter > > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Test email (was: Stuck on Config Setup with IBM x3650 and CentOS7 )
At Mon, 23 Oct 2017 12:21:26 -0500 Benjammin2068 wrote: > > Content-Language: en-US > > > I'm not getting list mails to my gmail account for some reason.. I may end > up switching email accounts if I don't see this email come through. When you post to a Mailman list from a GMail account, Google *helpfully* suppresses the redundent (?) e-mail. This is a feature, not a bug (TM) :-) > > My previous post (Stuck on Config Setup with IBM x3650 and CentOS7) > <https://lists.x.org/archives/xorg/2017-October/058945.html> was replied to > but I never got any emails except the normal subscribe messages. (boo) > > > (thanks Adam -- BTW the "power outage" was a UPS battery going dead while > the power company was changing a meter. Not a storm. the video card works. I > can see the startup splash... I never get a gnome login.) > > p.s. I saw the other post from this month with RHEL 7.4 and I think I'm > having the same problem since it's the same ATI/ES1000 series card.) > > > Â -Ben > > > MIME-Version: 1.0 > > ___ > 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 > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: what LLVM does mesa need to build "r300" ?
At Sun, 10 Jun 2018 10:41:22 -0400 Dennis Clarke wrote: > > > > Dear Xorg: > > For some days now I have been going in circles trying to get a > build going from git but endlessly run into oddball dependecy issues on > Debian buster : > > . > . > . > checking for RADEON... yes > configure: error: --enable-llvm is required when building r300 > build.sh: "./autogen.sh" failed on mesa/mesa > build.sh: error processing: "mesa/mesa" You probably need to pass "--enable-llvm" to build.sh or else edit build.sh to include --enable-llvm on the command line to configure or autogen.sh. > > OKay .. however I have that : > > fs$ dpkg-query -l | grep -i "llvm" > ii libllvm5.0:amd641:5.0.2-2 amd64 > Modular compiler and toolchain technologies, runtime librar > ii llvm-5.01:5.0.2-2 amd64 > Modular compiler and toolchain technologies > ii llvm-5.0-dev1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, libraries and > ii llvm-5.0-runtime1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, IR interpreter > ii llvm-5.0-tools 1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, tools > fs$ > > Do I need a particular colour or flavour or ? Sorry for the sarcasm > but I have seen some interesting dependencies pop up such as python mako > template jazz. A lot sure has changed in a few years. > > Any hints? > > > Dennis > > > > ___ > 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 > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: SLow Caps lock Bug
At Wed, 17 Jul 2019 14:14:52 +0700 Winston Purnomo wrote: > > > > To whom this may concern, > > I am writing today to add my voice to the longstanding complaints that the > Caps LOck off key is very slow to respond, which makes double uppercase > letters LIke this more common than I'd like when typing. This is an issue > that has stood since at least 2010 on many message boards, and a solution > to this would be much appreciated. Why are you using Caps Lock for single uppercase letters? Or do you mean the Shift key? And this sounds more like a hardware issue (relating to your keyboards mechanical behaviour (sticky keys or something like that). > > Thank you. > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Suggestion for Xorg / about middle-mouse click pasting
ain 3-button mice are no-longer available (I've not seen them anywhere). (Maybe there are few in an old wearhouse somewhere, keeping company with a few DEC LK-450 keyboards.) > > Cheers, > Adam. > ___ > 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 > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Suggestion for Xorg / about middle-mouse click pasting
At Thu, 30 Jul 2020 14:39:04 -0400 Elie Goldman Smith wrote: > > > > Countless people on forums say that middle-mouse pasting is an X11 feature. > > This document seems to confirm that it's an X11 feature: > https://www.jwz.org/doc/x-cut-and-paste.html > > > Please correct me if I'm wrong. The original mice on Sun, DEC, and SGI workstations of the late 1970s through the mid/late 1980s all had 3 buttons. A common *usage* by *UNIX* users was to use the middle button for pasting (text). This was (and still is) a standard binding for xterms (the original XAW flavored xterm). In those days, most applications did not bother with a "right button" context menu (that would feature "Cut, Copy, Paste" items on it and many applications might not have a menu bar (xterms don't and also don't have a "right button" context menu wither). The text editor of choice of the *UNIX* users of that time was either vi or Emacs, neither of which had a GUI (aka point-and-click) version (at the time). Word processing barely existed at all and not at all on *UNIX* workstations. So, copy and paste was pretty much only a matter of highlighting with the left button and pasting with the middle button. X11 itself did not (and xorg still does not) define this behaviour. (And yes, *I* still use old school xterms -- I find all of the "modern" -term programs obnoxious.) All X11/xorg does is pass pointer events with possible button state modifiers. The *applications* implement what happens (or does not happen) with those events. It became a convention to implement the middle button as the paste button. Many "modern" applications implement context menus and/or have menu bars with Edit menus, either/both include cut, copy, and paste menu items. Old school xterms *still* don't implement either a context menu (right button) or have a menu bar (and thus don't have an edit menu). People who learned computers under MacOS or MS-Windows never learned this usage, since neither Macs or "PCs" (MS-Windows) ever had plain middle buttons, unless some *UNIX* (Linux) hacker connected one. Native MacOS (Classic or X) and MS-Windows applications never defined any sort of behaviour for middle buttons, since those machines never had middle buttons and thus people starting to use Linux are "suddenly" seeing this behaviour which appears novel to them and don't understand it. This is *especially* true when they mostly use "modern" applications that mimic MacOS or MS-Windows usage (and thus have context menus and/or edit menus), and *sometimes* also implement middle button paste, which in that context appears redundant and/or extrainious. The thing is the context menus and/or edit menus are the (so-called) "user friendly" add-ons. Get over it. If it *really* bothers you, go back to your toy machines running their toy operating systems. And leave us UNIX/Linux users' middle buttons alone. > > > On Friday, July 24, 2020, Alan Coopersmith > wrote: > > > On 7/23/20 1:19 AM, Elie Goldman Smith wrote: > > > >> Solution: > >> Middle-mouse pasting would be great as a setting that can be > >> enabled/disabled by 'xset' on the command line. > >> > >> Please let me know if this would be simple to implement. > >> > > > > It would not be, because it is not a X server behavior. It is simply > > a convention implemented in dozens of toolkits and thousands of > > applications, with no centralized control. > > > > All the X server does is tell the client that button 2 was pressed, and > > everything after that happens client side. > > > > -- > > -Alan Coopersmith- alan.coopersm...@oracle.com > > Oracle Solaris Engineering - https://blogs.oracle.com/alanc > > > > MIME-Version: 1.0 > > ___ > 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 > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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: Suggestion for Xorg / about middle-mouse click pasting
At Fri, 31 Jul 2020 19:16:14 -0400 Sam Varshavchik wrote: > > On Fri, Jul 31, 2020 at 4:37 PM Adam Jackson wrote: > > > > (accidentally sent to just sam initially, whoops) > > Yes, and just had a two minute look at it -- this just seems to > disable pasting of the PRIMARY selection, completely. > > I suppose that's one way to disable the middle mouse click. As well as > the "Paste" option from most applications' "Edit" menu, and/or the > equivalent keyboard combination. > > I suppose that this is one way to fix the problem. It should be noted that is an answer in search of a (mostly non-existant) problem. Most of us long-term UNIX and Linux users don't "accidentally" click the middle button. This is going to be mostly an issue for people moving to Linux from MS-Windows (or possibly MacOS) who have managed to develope a "bad habit" with respect to randomly clicking the middle button. Clicking the middle button under MS-Windows (and MacOS), is a noop and so a "nervous twitch" the clicks it is harmless and will go unnoticed. And yes this fix pretty much disables even context and Edit menu paste functions as well, which is not actually what the OP wanted. > > > > > > > > On Fri, Jul 31, 2020 at 7:22 AM Sam Varshavchik > > wrote: > > > On Fri, Jul 31, 2020 at 4:30 AM Böszörményi Zoltán > > > wrote: > > > > 2020. 07. 30. 21:20 keltezéssel, Dennis Clarke ÃÂrta: > > > > > On 7/30/20 6:39 PM, Elie Goldman Smith wrote: > > > > >> Countless people on forums ... > > > > > > > > > > Also they are not the source code nor would I rely on what countless > > > > > people say on just about any matter whatsoever. I am not sure when > > > > > the horrific "popular is correct" logic became almost defacto pure > > > > > truth but I reject it. I am certain I am not alone but I also do not > > > > > have a mathematical proof handy to refute the "popular is correct" > > > > > notion. At least not yet. > > > > > > > > Let me suggest an analogue / convergent notion, which is also popular > > > > among engineers: "ten billion flies can't be wrong. let's eat sh*t" > > > > I am not sure this refutes the "popular is correct" logic but it > > > > certainly puts things into perspective. > > > > > > That's somewhat besides the point. The point is that the server has > > > absolutely no control over this functionality. Anyone who actually > > > knows and understands X11 (and not some uncounted number of people in > > > some mysterious forums) will know that. > > > > > > If someone believes otherwise, they are free to download the source to > > > the Xorg server, make whatever the change they believe will adjust > > > that behavior, and prove everyone else wrong. > > > > Fine, I'm feeling contrarian: > > > > https://gitlab.freedesktop.org/snippets/1127 > > > > The server _absolutely_ has control over this. The value of the > > PRIMARY property, from the requesting client's perspective, is > > whatever the server says it is. There's no reason the server needs to > > tell you the truth. I'm pretty sure you could craft selinux policy to > > do this and not even need to patch your server. > > > > The point is: opinions about this are not universal. PRIMARY's > > behaviour is so thoroughly baked into both client software and a > > non-trivial subset of user expectation that anyone saying "obviously > > it should be turned off" is projecting. Likewise anyone who cut their > > teeth on a sun3 and thinks UI design was perfected with the Athena > > widget set is intentionally ignoring the absolutely massive > > popularization of access to computing since 1992. > > > > Nobody needs a manifesto about this. If you want to improve the world > > here the quantity of code needed is really quite small. I would like > > to think the xorg developers are friendly and approachable enough that > > people would feel comfortable asking how to make these kinds of > > changes and where to start hacking. We've done tremendous amounts of > > work over the last 15-odd years to eliminate the irrelevant code and > > make what's left pleasant to work on. Please don't make me feel like > > that's been wasted effort. > > >
nouveau going off the deep end...
719] nouveau :02:00.0: gr: PGRAPH_VSTATUS1: [] Jun 19 16:09:10 sauron kernel: [860991.231369] nouveau :02:00.0: gr: PGRAPH_VSTATUS2: [] Jun 19 16:09:12 sauron kernel: [860993.232048] nouveau :02:00.0: gr: PGRAPH TLB flush idle timeout fail Jun 19 16:09:12 sauron kernel: [860993.232748] nouveau :02:00.0: gr: PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] Jun 19 16:09:12 sauron kernel: [860993.233414] nouveau :02:00.0: gr: PGRAPH_VSTATUS0: 0008 [CCACHE] Jun 19 16:09:12 sauron kernel: [860993.234078] nouveau :02:00.0: gr: PGRAPH_VSTATUS1: [] Jun 19 16:09:12 sauron kernel: [860993.234726] nouveau :02:00.0: gr: PGRAPH_VSTATUS2: [] Jun 19 16:09:14 sauron kernel: [860995.235397] nouveau :02:00.0: gr: PGRAPH TLB flush idle timeout fail Jun 19 16:09:14 sauron kernel: [860995.236095] nouveau :02:00.0: gr: PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] Jun 19 16:09:14 sauron kernel: [860995.236820] nouveau :02:00.0: gr: PGRAPH_VSTATUS0: 0008 [CCACHE] Jun 19 16:09:14 sauron kernel: [860995.237541] nouveau :02:00.0: gr: PGRAPH_VSTATUS1: [] Jun 19 16:09:14 sauron kernel: [860995.238253] nouveau :02:00.0: gr: PGRAPH_VSTATUS2: [] Jun 19 16:09:16 sauron kernel: [860997.238929] nouveau :02:00.0: gr: PGRAPH TLB flush idle timeout fail Jun 19 16:09:16 sauron kernel: [860997.239628] nouveau :02:00.0: gr: PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] Jun 19 16:09:16 sauron kernel: [860997.240352] nouveau :02:00.0: gr: PGRAPH_VSTATUS0: 0008 [CCACHE] Jun 19 16:09:16 sauron kernel: [860997.241075] nouveau :02:00.0: gr: PGRAPH_VSTATUS1: [] Jun 19 16:09:16 sauron kernel: [860997.241780] nouveau :02:00.0: gr: PGRAPH_VSTATUS2: [] Jun 19 16:09:27 sauron kernel: [861008.278250] sysrq: Keyboard mode set to system default Jun 19 16:09:31 sauron kernel: [861012.243328] nouveau :02:00.0: systemd-logind[2692]: failed to idle channel 3 [systemd-logind[2692]] -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: nouveau going off the deep end...
I don't use any other 3D programs (maybe FreeCAD). KiCaD is not a 3D program, it is 2D. This is an integrated video chipset on the motherboard -- I don't have a separate video card. How do I turn off the compositor? Do I need it? At Sun, 19 Jun 2022 17:03:28 -0400 (EDT) Vladimir Dergachev wrote: > > > > On Sun, 19 Jun 2022, Robert Heller wrote: > > > I am running Ubuntu 18.04 on an AMD Phenom(tm) II X4 945 Processor, 8Gig of > > RAM, with a NVIDIA Corporation C77 [GeForce 8200] (rev a2) video chipset. > > There is some sort of bug in the version of KiCaD I have > > (4.0.7+dfsg1-1ubuntu2) with its pcbnew program that puts my machine in a > > state > > where I have to use the "magic" SysRq key to forceably reboot it (I can ssh > > in > > from another computer, but /sbin/reboot does not work). > > Judging by the messages it looks like a lockup in a video card. > > Do other 3d programs run fine ? Try a 3d-game like quake or similar. > > Try turning off the compositor. Also keep in eye on the fan and GPU > temperature. > > It could be a bug in the driver, but nouveau worked quite well for me on > both 18.04 and 20.04 for many years. > > best > > Vladimir Dergachev > > > > > I've included the last of the kernel log. It looks like something is broken > > in nouveau, which I am guessing has something to do with the video somehow. > > (And no, I am not going to download and install NVIDIA's video driver.) > > > > I don't know if this is a kernel problem (I current have kernel > > 4.15.0-187-generic), or something in X Server. > > > > Jun 19 16:08:38 sauron kernel: [860959.174609] nouveau :02:00.0: gr: > > PGRAPH TLB flush idle timeout fail > > Jun 19 16:08:38 sauron kernel: [860959.175311] nouveau :02:00.0: gr: > > PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > > Jun 19 16:08:38 sauron kernel: [860959.175982] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS0: 0008 [CCACHE] > > Jun 19 16:08:38 sauron kernel: [860959.176651] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS1: [] > > Jun 19 16:08:38 sauron kernel: [860959.177303] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS2: [] > > Jun 19 16:08:40 sauron kernel: [860961.177974] nouveau :02:00.0: gr: > > PGRAPH TLB flush idle timeout fail > > Jun 19 16:08:40 sauron kernel: [860961.178678] nouveau :02:00.0: gr: > > PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > > Jun 19 16:08:40 sauron kernel: [860961.179406] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS0: 0008 [CCACHE] > > Jun 19 16:08:40 sauron kernel: [860961.180074] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS1: [] > > Jun 19 16:08:40 sauron kernel: [860961.180727] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS2: [] > > Jun 19 16:08:42 sauron kernel: [860963.181410] nouveau :02:00.0: gr: > > PGRAPH TLB flush idle timeout fail > > Jun 19 16:08:42 sauron kernel: [860963.182059] nouveau :02:00.0: gr: > > PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > > Jun 19 16:08:42 sauron kernel: [860963.182730] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS0: 0008 [CCACHE] > > Jun 19 16:08:42 sauron kernel: [860963.183398] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS1: [] > > Jun 19 16:08:42 sauron kernel: [860963.184051] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS2: [] > > Jun 19 16:08:44 sauron kernel: [860965.184723] nouveau :02:00.0: gr: > > PGRAPH TLB flush idle timeout fail > > Jun 19 16:08:44 sauron kernel: [860965.185425] nouveau :02:00.0: gr: > > PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > > Jun 19 16:08:44 sauron kernel: [860965.186153] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS0: 0008 [CCACHE] > > Jun 19 16:08:44 sauron kernel: [860965.186879] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS1: [] > > Jun 19 16:08:44 sauron kernel: [860965.187587] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS2: [] > > Jun 19 16:08:46 sauron kernel: [860967.188320] nouveau :02:00.0: gr: > > PGRAPH TLB flush idle timeout fail > > Jun 19 16:08:46 sauron kernel: [860967.189022] nouveau :02:00.0: gr: > > PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > > Jun 19 16:08:46 sauron kernel: [860967.189760] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS0: 0008 [CCACHE] > > Jun 19 16:08:46 sauron kernel: [860967.190429] nouveau :02:00.0: gr: > > PGRAPH_VSTATUS1: [] > > Jun 19 16:08:46 sauron kernel: [860967.191082] nouveau :02:00.0: gr: > > PGRA
Re: nouveau going off the deep end...
At Sun, 19 Jun 2022 22:42:28 -0400 (EDT) Vladimir Dergachev wrote: > > > > On Sun, 19 Jun 2022, Robert Heller wrote: > > > I don't use any other 3D programs (maybe FreeCAD). KiCaD is not a 3D > > program, > > it is 2D. This is an integrated video chipset on the motherboard -- I don't > > have a separate video card. > > Nowadays a lot of rendering goes through 3d engine - as long as one has > capability, why not ? And it makes it easier to work with images, alpha, > etc. > > Thus just because a program is 2d does not mean it does not use the 3d > graphics. > > For example, one of the simplest way to make a movie player that is > capable of displaying multiple streams is to use opengl to paint frames on > 2d faces. It could make a rotating cube, of course, but that is hard to > watch :) > > > > > How do I turn off the compositor? Do I need it? > > Look in settings - this depends on whether you use KDE or unity or > something else. I use "something else": Mate, but with FVWM as the window manager and without the menu crap and without the file manager. > > The compositor is used for desktop effects like window zoom or making your > windows partially transparent. > > Another suggestion is to try upgrading to 20.04. > > best > > Vladimir Dergachev > > > > > At Sun, 19 Jun 2022 17:03:28 -0400 (EDT) Vladimir Dergachev > > wrote: > > > >> > >> > >> > >> On Sun, 19 Jun 2022, Robert Heller wrote: > >> > >>> I am running Ubuntu 18.04 on an AMD Phenom(tm) II X4 945 Processor, 8Gig > >>> of > >>> RAM, with a NVIDIA Corporation C77 [GeForce 8200] (rev a2) video chipset. > >>> There is some sort of bug in the version of KiCaD I have > >>> (4.0.7+dfsg1-1ubuntu2) with its pcbnew program that puts my machine in a > >>> state > >>> where I have to use the "magic" SysRq key to forceably reboot it (I can > >>> ssh in > >>> from another computer, but /sbin/reboot does not work). > >> > >> Judging by the messages it looks like a lockup in a video card. > >> > >> Do other 3d programs run fine ? Try a 3d-game like quake or similar. > >> > >> Try turning off the compositor. Also keep in eye on the fan and GPU > >> temperature. > >> > >> It could be a bug in the driver, but nouveau worked quite well for me on > >> both 18.04 and 20.04 for many years. > >> > >> best > >> > >> Vladimir Dergachev > >> > >>> > >>> I've included the last of the kernel log. It looks like something is > >>> broken > >>> in nouveau, which I am guessing has something to do with the video > >>> somehow. > >>> (And no, I am not going to download and install NVIDIA's video driver.) > >>> > >>> I don't know if this is a kernel problem (I current have kernel > >>> 4.15.0-187-generic), or something in X Server. > >>> > >>> Jun 19 16:08:38 sauron kernel: [860959.174609] nouveau :02:00.0: gr: > >>> PGRAPH TLB flush idle timeout fail > >>> Jun 19 16:08:38 sauron kernel: [860959.175311] nouveau :02:00.0: gr: > >>> PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > >>> Jun 19 16:08:38 sauron kernel: [860959.175982] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS0: 0008 [CCACHE] > >>> Jun 19 16:08:38 sauron kernel: [860959.176651] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS1: [] > >>> Jun 19 16:08:38 sauron kernel: [860959.177303] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS2: [] > >>> Jun 19 16:08:40 sauron kernel: [860961.177974] nouveau :02:00.0: gr: > >>> PGRAPH TLB flush idle timeout fail > >>> Jun 19 16:08:40 sauron kernel: [860961.178678] nouveau :02:00.0: gr: > >>> PGRAPH_STATUS 0501 [BUSY CTXPROG CCACHE_PREGEOM] > >>> Jun 19 16:08:40 sauron kernel: [860961.179406] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS0: 0008 [CCACHE] > >>> Jun 19 16:08:40 sauron kernel: [860961.180074] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS1: [] > >>> Jun 19 16:08:40 sauron kernel: [860961.180727] nouveau :02:00.0: gr: > >>> PGRAPH_VSTATUS2: [] > >>> Jun 19 16:08:42 sauron kernel: [860963.181410] nouveau :02:00.0: gr: > >>> PGRAPH TLB flush idle timeout fail > >>> Jun 19 16:08:42 sa
Re: nouveau going off the deep end...
At Mon, 20 Jun 2022 00:10:24 -0400 Felix Miata wrote: > > Robert Heller composed on 2022-06-19 16:31 (UTC-0400): > > > I am running Ubuntu 18.04 on an AMD Phenom(tm) II X4 945 Processor, 8Gig of > > RAM, with a NVIDIA Corporation C77 [GeForce 8200] (rev a2) video chipset. > > There is some sort of bug in the version of KiCaD I have > > (4.0.7+dfsg1-1ubuntu2) with its pcbnew program that puts my machine in a > > state > > where I have to use the "magic" SysRq key to forceably reboot it (I can ssh > > in > > from another computer, but /sbin/reboot does not work). > > > I've included the last of the kernel log. It looks like something is > > broken > > in nouveau, which I am guessing has something to do with the video somehow. > > > > (And no, I am not going to download and install NVIDIA's video driver.) > > > I don't know if this is a kernel problem (I current have kernel > > 4.15.0-187-generic), or something in X Server. > > You're using the nouveau kernel driver, but are you using the nouveau DDX > display > driver, or the modesetting DIX display driver? Does switching to the other > make > any difference? I am not sure -- I don't have a X config file - the X server is using its defaults. sauron% inxi -xxx -GS System:Host: sauron Kernel: 4.15.0-187-generic x86_64 bits: 64 gcc: 7.5.0 Desktop: MATE 1.20.1 (Gtk 2.24.32) info: mate-panel dm: N/A Distro: Ubuntu 18.04.6 LTS Graphics: Card: NVIDIA C77 [GeForce 8200] bus-ID: 02:00.0 chip-ID: 10de:0849 Display Server: X.Org 1.19.6 driver: nouveau Resolution: 1366x768@59.79hz OpenGL: renderer: NVAA version: 3.3 Mesa 20.0.8 Direct Render: Yes > > I have a little bit newer NV84, also with Tesla architecture used by GeForce > 8200, > working normally on 18.04, using modesetting DIX: > > # inxi -GSaz --vs > inxi 3.3.19 (2022-06-17) > System: > Kernel: 4.15.0-187-generic arch: x86_64 bits: 64 compiler: gcc v: 7.5.0 > parameters: ro root=LABEL= net.ifnames=0 ipv6.disable=1 > noresume mitigations=auto consoleblank=0 plymouth.enable=0 > Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0 > vt: 7 dm: TDM Distro: Ubuntu 18.04.6 LTS (Bionic Beaver) > Graphics: > Device-1: NVIDIA G84 [GeForce 8600 GT] vendor: XFX Pine driver: nouveau > v: kernel alternate: nvidiafb non-free: 340.xx > status: legacy (EOL, try --gpu) arch: Tesla process: 40-80nm > built: 2006-13 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports: > active: DVI-I-1,DVI-I-2 empty: none bus-ID: 01:00.0 chip-ID: 10de:0402 > class-ID: 0300 > Display: x11 server: X.Org v: 1.19.6 driver: X: loaded: modesetting > alternate: fbdev,nouveau,vesa gpu: nouveau display-ID: :0 screens: 1 > Screen-1: 0 s-res: 3840x1200 s-dpi: 120 s-size: 812x254mm (31.97x10.00") > s-diag: 851mm (33.5") > Monitor-1: DVI-I-1 pos: primary,left model: NEC EA243WM serial: > built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 > size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes: > max: 1920x1200 min: 640x480 > Monitor-2: DVI-I-2 pos: right model: Samsung built: 2009 res: 1920x1080 > hz: 60 dpi: 305 gamma: 1.2 size: 160x90mm (6.3x3.54") diag: 184mm (7.2") > ratio: 16:9 modes: max: 1920x1080 min: 720x400 > OpenGL: renderer: NV84 v: 3.3 Mesa 20.0.8 direct render: Yes -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Question about the future of Xorg
Yes, there are some of us who can't move to Wayland. In my case FVWM is not able to work with Wayland and FVWM2 is my Window Manager of choice. I don't know if *I* want to do something like take over Xorg all on my own. At Sat, 7 Jun 2025 14:19:24 -0600 Felipe Contreras wrote: > > Hello, > > I've often heard that there's only one developer working on Xorg, and > apparently not anymore. I want to find out if that's true. > > I'm writing an article about the people committed to keep working on > Xorg in the future, and if there's any I would like to ask them a few > questions. > > Is there anyone who is going to keep maintaining Xorg indefinitely? > > Cheers. > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Question about the future of Xorg
At Mon, 9 Jun 2025 17:13:09 -0600 Felipe Contreras wrote: > > On Mon, Jun 9, 2025 at 8:27â¯AM Lyude Paul wrote: > > > X wasn't "badly designed" per-say, for what it was I'll absolutely say it > > was a wonderful piece of software and it did its job well. But it's also > > designed for an era of computing that is much different than how most > > modern desktops work, so for a lot of the functionality we wanted to see in > > Wayland the only way to have implemented it in X would have required > > breaking people's setups. So, technically speaking splitting the > > development off was kind of a given in some sense anyway. Even if we didn't > > move work to Wayland it's more likely work would have been on an X server > > that didn't really resemble X11 and wasn't 1:1 compatible. > > You can list a million reasons why Wayland is superior, but people > still use Xorg, and my bet is that's going to continue to be the case > for at least a decade, and possibly much more. The key part of what Lyude Paul wrote is "But it's also designed for an era of computing that is much different than how most modern desktops work...". There are some of "us" who have no use for "modern" desktop environments. Maybe we actually prefer "old fashioned" desktop environments. So, we will continue to use Xorg (X11). Unless/until Wayland develops some kind of whatever that fully supports / mimics the "old fashioned" features of X11 in a compaticable way (so "standard" X11 Window Managers, like FVWM can work), Wayland is just not going to work for us, no matter how spiffy it is -- *I* don't need a spiffy GUI subsystem, something that is boring that actually works the way *I* want it to work is what I want. It is worth noting that "Dark Mode" terminal windows look and feel just like the 1970s vintage CRT terminals I used 50 years ago. To me *that* is seriously "old fashioned" and is commonly the standard default terminal for many "modern" desktops... Go figure. > > So if there are some users that will keep using Xorg, I would expect > there to be some developers that will keep developing Xorg. > > But for some reason no one other than Enrico Weigelt has raised their > hand and publicly stated so. > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
Re: Question about the future of Xorg
> that app - the display system is a massive leaking hole you cant plug... and > > this is one of the things wayland wants to address and does. > > My number one step now after installing Kubuntu is to "de-snap" Firefox > and install a debian package. > > >> Screenshot is not perfect - you really want a video, so you can play an > >> animation. > > > > a screenshot is just 1 frame of a video... that is how zoom, teams and every > > video conf app works now today. they keep taking screenshots repeatedly and > > quickly. that's how they can "share my screen" over that video conference... > > they grab these frames then encode them into a video stream - on the fly. > > they > > do that in x11 today... > > Yes, but ideally you could do it in such a way as to guarantee a frame > every 1/N seconds and also guarantee that a frame is fully rendered to > avoid tearing. This is something that I think X cannot do right now. > > > > >> Another useful tool is screen recorder like vokoscreenNG - with it you can > >> record your talk to be played back later. Again, you want the ability to > >> record a video of the screen. > > > > guess how those work too... :) see above :) > > I was just giving an example of apps you want to have full screen access. > > > > > then this is certainly something your vnc viewer should support IMHO. as how > > much you want to scale THAT session may vary from target to target it is > > connecting to... and it should remember such scale settings machine by > > machine > > you register/connect to. the compositor has no clue what is inside that > > app's > > window. in wayland or x11. it's the app's business. > > Not really - I just run x11vnc on the remote and connect to it. I don't > start a new session, and I don't change fonts. Very handy, both to help > someone else and to use your desktop when you are away. > > best > > Vladimir Dergachev > > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
X11 vs Wayland: what does the timeline look like?
At this time it looks like I *cannot* switch to Wayland -- several things about Wayland just don't work (for me). I know of at least three things where Wayland simply fails: I use KiCAD and KiCAD just does not work with Wayland: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ I use FVWM2 as my window manager. And I believe FVWM2 uses features of X11 that are not available in Wayland. And no I don't like Gnome or KDE (or really *any* so-called "modern" desktop environment. Also I use SSH X11 tunneling very extensively. I have a whole LAN full of little Linux machines (mostly assorted 'Pis). Some of these are lower end machines that I don't want to run full-fledged desktop environments on and use RDP or VNC with, expecially just to run a simple X11 program on. So, is there a likely timeline where X11 (in whatever form that takes) "vanishes" and Wayland totally replaces it as the graphical server infratructure under Linux? Are we talking a few years, a decade, or several decades? -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
