Re: Intel G45 ModeLines
Eric Anholt wrote: > On Sun, 2008-12-07 at 06:48 +, Terry Barnaby wrote: >> Hi, >> >> I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung >> HDTV. >> I am using Fedora 10 as the base with the latest DRM/X11 driver from the >> Xorg GIT repository. In general this appears to be working. >> >> However, the TV's EDID is not correct in some details and so I wish to >> override >> some things in the "Monitor section of the xorg.conf file. However they do >> not >> seem to work. >> >> If I add: "DisplaySize 890 500" this is ignored. >> >> If I add: "ModeLine "1920x1080_50" 148.50 1920 2448 2492 2640 1080 1084 1089 >> 1125 +HSync +VSync" with a "Modes "1920x1080_50" " line in the "Screen" >> section >> this seems to be ignored. >> >> Is there any way to get the Intel driver to use a user provided ModeLine ? > > xorg.conf(5): >Option "PreferredMode" "string" > This optional entry specifies a mode to be marked as the > preferred ini‐ > tial mode of the monitor. (RandR 1.2-supporting drivers only) > > However the real preferred thing to do is write up a quirk for the > server to fix your EDID so that other people get the benefit of your > bugfixes. > Thanks for the reply. Setting the "PreferredMode" option had no effect. However, with some more research I found that I needed to add the line: Option "monitor-HDMI-1" "Monitor0" to my "Device" section. The Intel driver was assuming my default "Monitor" section referred to the VGA output rather than the HDMI-1 output although no VGA monitor was connected. Having done this my settings in the "Monitor" section are no longer ignored. I don't know if this is a feature or a bug ... Cheers Terry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (xserver)
Hi Paulo, > Correction just pushed. Thanks. > Do you also build on other architectures and operating systems? > I have interest at least in builds on Solaris and BSD. At the moment the three machines on http://tinderbox.x.org/ are Linux sparc64, Linux ppc64 and Linux i686, and I'd be happy to include others. The steps for setting up a new machine are: * Read http://tinderbox.x.org/participate, get a username/pass * Set up jhbuild; see http://wiki.x.org/wiki/JhBuildInstructions * "jhbuild build xorg-libs xserver xorg-drivers xorg-apps"; check that the build completes and you have the appropriate dependencies. * Once you're ready to add the machine to the tinderbox front page, set up a crontab such as: 0 */2 * * *bin/jhbuild autobuild -a -c --report-url="http://USER:[EMAIL PROTECTED]/builds/rpc" xorg-libs xserver xorg-drivers xorg-apps The tinderbox code can also launch the generated X server and perform checks/benchmarks against it, but I don't have easy instructions for how to do that with a new machine yet -- if someone wants to add that to a machine (the "construct" i686 machine does so already) let me know. Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (xserver)
> Hi, Hi, Thanks for the report. Correction just pushed. >> commit b1dac41fb3853ca8182048ea57b88b6e84ecceb3 >> Author: Paulo Cesar Pereira de Andrade <[EMAIL PROTECTED]> Date: >> Sun Dec 7 02:22:19 2008 -0200 >> >> Use libtool convenience libraries and better "symbol" table. > > http://tinderbox.x.org/builds/2008-12-07-0007/ > http://tinderbox.x.org/builds/2008-12-07-0007/logs/xserver/#build > > ./.libs/libxorg.a(sdksyms.o):(.data.rel+0x13d4): undefined reference to > `xf86acpiDisableFlag' > collect2: ld returned 1 exit status Do you also build on other architectures and operating systems? I have interest at least in builds on Solaris and BSD. > -- > Chris Ball <[EMAIL PROTECTED]> Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel G45 ModeLines
On Sun, 2008-12-07 at 06:48 +, Terry Barnaby wrote: > Hi, > > I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung > HDTV. > I am using Fedora 10 as the base with the latest DRM/X11 driver from the > Xorg GIT repository. In general this appears to be working. > > However, the TV's EDID is not correct in some details and so I wish to > override > some things in the "Monitor section of the xorg.conf file. However they do > not > seem to work. > > If I add: "DisplaySize890 500" this is ignored. > > If I add: "ModeLine "1920x1080_50" 148.50 1920 2448 2492 2640 1080 1084 1089 > 1125 +HSync +VSync" with a "Modes "1920x1080_50" " line in the "Screen" > section > this seems to be ignored. > > Is there any way to get the Intel driver to use a user provided ModeLine ? xorg.conf(5): Option "PreferredMode" "string" This optional entry specifies a mode to be marked as the preferred ini‐ tial mode of the monitor. (RandR 1.2-supporting drivers only) However the real preferred thing to do is write up a quirk for the server to fix your EDID so that other people get the benefit of your bugfixes. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Current tinderbox regression (xserver)
Hi, > commit b1dac41fb3853ca8182048ea57b88b6e84ecceb3 > Author: Paulo Cesar Pereira de Andrade <[EMAIL PROTECTED]> Date: > Sun Dec 7 02:22:19 2008 -0200 > > Use libtool convenience libraries and better "symbol" table. http://tinderbox.x.org/builds/2008-12-07-0007/ http://tinderbox.x.org/builds/2008-12-07-0007/logs/xserver/#build ./.libs/libxorg.a(sdksyms.o):(.data.rel+0x13d4): undefined reference to `xf86acpiDisableFlag' collect2: ld returned 1 exit status -- Chris Ball <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Intel G45 ModeLines
Hi, I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung HDTV. I am using Fedora 10 as the base with the latest DRM/X11 driver from the Xorg GIT repository. In general this appears to be working. However, the TV's EDID is not correct in some details and so I wish to override some things in the "Monitor section of the xorg.conf file. However they do not seem to work. If I add: "DisplaySize 890 500" this is ignored. If I add: "ModeLine "1920x1080_50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +HSync +VSync" with a "Modes "1920x1080_50" " line in the "Screen" section this seems to be ignored. Is there any way to get the Intel driver to use a user provided ModeLine ? Cheers Terry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Missing libX11 Headers
> "v" == vehemens <[EMAIL PROTECTED]> writes: v> Need to add big5hkscs.h and gbk.h to the distribution list. Thanks. Pushed as commit c34ce54d9eac2d8052dc5f205a2ab09866ef5d25. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
CyberBlade/i7d Dual Head Operation Possible?
Hello, I am trying to configure xorg.conf on a HP Pavilion N3330 to show one instance of X on its tilt-up screen and another instance of X on its external monitor. Currently, the external monitor shows the same content that the screen shows. Here is the transcribed output of Xorg -scanpci: (0:0:0) VIA Technologies, Inc. VT8501 [Apollo MVP4] (0:1:0) VIA Technologies, Inc. VT8501 [Apollo MVP4 AGP] (0:7:0) VIA Technologies, Inc. VT82C686 [Apollo Super South] (0:7:1) VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (0:7:2) unknown card (0x0925/0x1234) using a VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (0:7:4) VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (0:10:0) unknown card (0x1801/0x) using a 02 Micro, Inc. 0Z6812 CardBus Controller (0:13:0) unknown card (0x103c/0x000e) using a ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (0:13:1) unknown card (0x103c/0x000e) using a ESS Technology ES1983S Maestro-3i PCI Modem Accelerator (1:0:0) unknown card (0x103c/0x000f) using a Trident Microsystems CyberBlade/i7d lspci -v outputs... 00:00.0 Class 0600: 1106:0501 (rev 04) Flags: bus master, medium devsel, latency 16 Memory at 2000 (32-bit, prefetchable) [size=32M] Capabilities: [a0] AGP version 2.0 00:01.0 Class 0604: 1106:8501 Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: a000-afff Memory behind bridge: 4000-470f Prefetchable memory behind bridge: 4800-4f0f 00:07.0 Class 0601: 1106:0686 (rev 22) Flags: bus master, stepping, medium devsel, latency 0 00:07.1 Class 0101: 1106:0571 (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, stepping, medium devsel, latency 64 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) I/O ports at 1100 [size=16] Capabilities: [c0] Power Management version 2 00:07.2 Class 0c03: 1106:3038 (rev 10) Subsystem: 0925:1234 Flags: bus master, medium devsel, latency 128, IRQ 10 I/O ports at 3000 [size=32] Capabilities: [80] Power Management version 2 00:07.4 Class 8006: 1106:3057 (rev 30) Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00:0a.0 Class 0607: 1217:6872 (rev 05) Subsystem: 103c:0016 Flags: bus master, stepping, slow devsel, latency 168, IRQ 11 Memory at 22002000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 Memory window 0: 2400-27fff000 (prefetchable) Memory window 1: 2800-2bfff000 I/O window 0: 1800-18ff I/O window 1: 1c00-1cff 16-bit legacy interface ports at 0001 00:0d.0 Class 0401: 125d:1998 Subsystem: 103c:000e Flags: bus master, medium devsel, latency 128, IRQ 5 I/O ports at 3100 [size=256] Memory at 2200 (32-bit, non-prefetchable) [size=8K] Capabilities: [c0] Power Management version 2 00:0d.1 Class 0780: 125d:1999 Subsystem: 103c:000e Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 3200 [size=256] Capabilities: [c0] Power Management version 2 01:00.0 Class 0300: 1023:8420 (rev 5d) Subsystem: 103c:000f Flags: bus master, 66Mhz, medium devsel, latency 8, IRQ 5 Memory at 4000 (32-bit, non-prefetchable) [size=8M] Memory at 4080 (32-bit, non-prefetchable) [size=128K] Memory at 4100 (32-bit, non-prefetchable) [size=8M] Expansion ROM at 4800 [disabled] [size=64K] Capabilities: [80] AGP version 1.0 Capabilities: [90] Power Management version 1 lspci -t outputs... -[00]-+-00.0 +-01.0-[01]00.0 +-07.0 +-07.1 +-07.2 +-07.4 +-0a.0 +-0d.0 \-0d.1 I temporarily created entries for the external monitor by creating new sections for "Screen1", "Monitor1", and "Device1" in xorg.conf as shown immediately below, but startx changed the driver entries in the device section from "trident" to "vesa". This xorg.conf causes the errors shown in the log far below. #Special base config file used in Puppy Linux. # ** # Module section -- this section is used to specify # which dynamically loadable modules to load. # ** # Section "Module" Load "synaptics" # This loads the DBE extension module. Load"dbe" # Double buffer extension # This loads the miscellaneous extensions module, and disabl
Missing libX11 Headers
Need to add big5hkscs.h and gbk.h to the distribution list. reference commit: 2008-11-22 18:40:54 (GMT) 67e34d7a82ccd31f1208c0c43a6d58c3c05bf51 Added remaining xlib patch required for gb18030 support (#1573). --- libX11/src/xlibi18n/Makefile.am.org 2007-10-27 23:11:49.0 -0700 +++ libX11/src/xlibi18n/Makefile.am 2008-11-28 17:35:26.0 -0800 @@ -91,11 +91,13 @@ lcUniConv/ascii.h\ lcUniConv/big5.h\ lcUniConv/big5_emacs.h\ + lcUniConv/big5hkscs.h\ lcUniConv/cp1133.h\ lcUniConv/cp1251.h\ lcUniConv/cp1255.h\ lcUniConv/cp1256.h\ lcUniConv/gb2312.h\ + lcUniConv/gbk.h\ lcUniConv/georgian_academy.h\ lcUniConv/georgian_ps.h\ lcUniConv/iso8859_1.h\ --- libX11/src/xlibi18n/Makefile.am.org 2007-10-27 23:11:49.0 -0700 +++ libX11/src/xlibi18n/Makefile.am 2008-11-28 17:35:26.0 -0800 @@ -91,11 +91,13 @@ lcUniConv/ascii.h\ lcUniConv/big5.h\ lcUniConv/big5_emacs.h\ + lcUniConv/big5hkscs.h\ lcUniConv/cp1133.h\ lcUniConv/cp1251.h\ lcUniConv/cp1255.h\ lcUniConv/cp1256.h\ lcUniConv/gb2312.h\ + lcUniConv/gbk.h\ lcUniConv/georgian_academy.h\ lcUniConv/georgian_ps.h\ lcUniConv/iso8859_1.h\ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken X11 After Mandriva Upgrade
Thanks for that information. I assumed (yes, I know what that does) that because there were errors that it was not running. I have had so much trouble with this I never bothered to try it. However this is the most progress I've made. I now can start X11 and it brings up the KDE desktop. Unfortunately that is as far as I can get. The mouse goes haywire. No matter where I try to move it, it jumps back to the top of the screen immediately. If I move it very fast I can get it 1/2 way down the screen before it jumps back. This is a Microsoft infared, PS2/USB mouse (I have it connected to the PS2 port). I chose the microsoft mouse option in the config and did not select 3buttonemulation. I also have a KVM switch and when I switch away from Mandriva, then back the mouse ceases to funciton. Also, at this point I have to log in and run 'startx'. It is not starting on boot and presenting the X11 login on the console. While I'm making progress, I am not home free yet. It is amazing how problematic this has become after working so well for so long prior to this upgrade. It seems every single time I upgrade Mandriva something breaks that takes weeks to fix. Dan Nicholson wrote: The socket, in this case, is the dbus system socket used to register the session with ConsoleKit. Probably, you don't have dbus running, but that shouldn't matter here. Things like HAL talk to ConsoleKit, but this doesn't matter for just running a regular X session. The "Using vt 7" message just means that the server is running on virtual terminal 7. I.e., tty7. You'll have to look further in the log file to see what video driver was actually loaded. _ Send e-mail anywhere. No map, no compass. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: MPX window managers?
On Sat, Dec 06, 2008 at 08:23:22PM -0500, Chris Ball wrote: > Are there any MPX window managers maintained/working, or plans to choose > one to maintain? The ones I've tried (the metacity branch¹, mpwm repo², > and compiz repo³) all fail to compile against HEAD, using old calls like > XGetPairedPointer(), XExtendedUngrabDevice() and WindowAccessDenyAll(). mpwm is dead, and it's for the better. compiz has recently been picked up and improved: http://smspillaz.wordpress.com/2008/10/16/compiz-fusion-mpx-support-is-complete/ (note, haven't tested it myself) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
MPX window managers?
Hi, Are there any MPX window managers maintained/working, or plans to choose one to maintain? The ones I've tried (the metacity branch¹, mpwm repo², and compiz repo³) all fail to compile against HEAD, using old calls like XGetPairedPointer(), XExtendedUngrabDevice() and WindowAccessDenyAll(). Thanks, - Chris. ¹: http://live.gnome.org/Metacity/MpxHowto ²: http://cgit.freedesktop.org/~whot/mpwm/ ³: http://cgit.freedesktop.org/~whot/compiz/ -- Chris Ball <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On 1 Dec 2008, David Miller verbalised: > A default that, btw, anti-socially totally ignores what people put > into their xorg.conf file unless they add yet another knob. That's > worse than a default change. What's worse yet is that hal is the single most unstable daemon I have *ever* run on any system I administer. My logs show that for more than half the time over the last two years it has refused to start: it coredumped on startup for a long time, for reasons that changed two or three times as I tracked the development HAL in hopes of it getting fixed, then started working, then some change in 2.6.27 made it freeze on startup: this now seems to be fixed in the stable tree, but, still, robust software this is not. I didn't care enough to track any of these problems down myself because on my fixed-hardware desktop HAL is basically a waste of memory: the hardware doesn't change and I know what I've got. I checked enough to make sure there was a bug reported, then moved on. So I was... somewhat annoyed to discover that when upgrading to xserver 1.5.3 I had to add 'AllowEmptyInput false', particularly given that the option name gives you no clue whatsoever as to why on earth this would make the keyboard reappear, and even the git logs give no rationale. I still have no idea why anyone would consider this behaviour desirable, particularly if you're loading kbd but are not loading evdev. IMHO, if the daemon isn't running at all, AllowEmptyInput should be unnecessary, and kbd/mouse should be consulted if loaded, *whether or not* the server was compiled with HAL support. Anything else is just too prone to failure. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
On 1 Dec 2008, Mikhail Gusarov stated: > The problem is more general: there are "desktop" services which don't have > good > policy clients beside the ones tied to major DEs: Bluetooth, NetworkManager, > HAL > come to mind. They all need a Unix-style clients to be written, so those who > don't use DE may easily configure the corresponding services. Indeed. I'm not aware of a HAL or d-bus configuration client for *anything*, GNOME or KDE: apparently you're supposed to set all this policy by hacking XML by hand. What fun. (If there is such a client, it's not well publicized.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGE protocol spec
On Fri, Dec 05, 2008 at 04:22:40PM -0500, Jim Gettys wrote: > A couple comments below. > > On Mon, 2008-12-01 at 16:15 +1000, Peter Hutterer wrote: > > Below is the protocol spec for the X Generic Event Extension (XGE). It'll be > > shipped with 1.6 even though there won't be any consumers for it yet. > > (This is the current proto/xextproto/geproto.txt file as valid in my tree. > > Will > > be pushed pending no objections.) > > > > Cheers, > > Peter > > > > X Generic Event Extension > > Peter Hutterer > > [EMAIL PROTECTED] > > > > > > 1. Introduction > > 2. Extension Initialization > > 3. Extension Events > > 4. Notes > > > > _ > > 1. Introduction > > > > X was designed to provide 64 event opcodes for all extensions. These events > > are limited to 32 bytes. > > > > The Generic Event Extension is a template for extensions to re-use a single > > event opcode. GE only provide headers and the most basic functionality, > > leaving the extensions to interpret the events in their specific context. > > > > GenericEvents may be longer than 32 bytes. If so, the number of 4 byte units > > following the initial 32 bytes must be specified in the length field of the > > event. > > 1.1 History and Rationale > > The original rationale for X11's fixed event size was that certain > platforms (notably VAX/VMS) had very poor malloc and free C library > implementations with terrible performance (both CPU and memory usage). > Malloc's memory usage with the then common Berkeley 4.2 allocator tended > to be profligate in space. By using a single event size both memory > fragmentation and performance problems were avoided. Retaining this > restriction on modern systems would continue to complicate X's evolution > and implementation unnecessarily. Is this necessary? While it may be interesting for someone researching the history of X, for an extension specification it's probably better to just state what is the current state and what the extension provides over the current state. > > _ > > 3. Extension Events > > > > GE defines a single event, to be used by all extensions. The event's > > structure > > is similar to a request. > > > > ┌─── > > RRScreenChangeNotify > > type: BYTE; always GenericEvent > > extension: CARD8; extension offset > > sequenceNumber: CARD16 low 16 bits of request seq. number > > length: CARD32 time screen was changed > > evtype: CARD16 event type > > └─── > > > > Do you really want to leave this only 16 bit aligned? Would two bytes > of padding be wise here? I suspect we do it's padded out to 32 bytes, just like replies. As replies, an event with length 0 is 32 bytes. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken X11 After Mandriva Upgrade
On Sat, Dec 6, 2008 at 2:12 PM, - gw1500se <[EMAIL PROTECTED]> wrote: > I had to rebuild the RPM database since I got an error trying the uninstall. > Then when I did the uninstall it said that driver was not installed. So I > proceeded to install the suggested version. The install seemed to work fine. > Unfortunately, nothing has changed. When I 'startx', I get the following: > > X Window System Version 1.3.0 > Release Date: 19 April 2007 > X Protocol Version 11, Revision 0, Release 1.3 > Build Operating System: Linux_2.6.24.5-server-2mnb Mandriva > Current Operating System: Linux dap002 2.6.22.9-desktop-1mdv #1 SMP Thu Sep > 27 04:07:04 CEST 2007 i686 > Build Date: 07 August 2008 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Sat Dec 6 17:02:06 2008 > (==) Using config file: "/etc/X11/xorg.conf" > Using vt 7 > (II) Module already built-in > (II) Module already built-in > xinit: No such file or directory (errno 2): Cannot register with > ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: > Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or > directory > SetClientVersion: 0 9 > SetGrabKeysState - disabled > > At this stage, X is running but I cannot start any sessions. It appears to > me that what ever process creates that socket is not installed or is not > running. I also question the line that says "Using vt 7" rather then saying > something about 'i810'. My xorg.conf has the driver set to 'i810'. The socket, in this case, is the dbus system socket used to register the session with ConsoleKit. Probably, you don't have dbus running, but that shouldn't matter here. Things like HAL talk to ConsoleKit, but this doesn't matter for just running a regular X session. The "Using vt 7" message just means that the server is running on virtual terminal 7. I.e., tty7. You'll have to look further in the log file to see what video driver was actually loaded. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
"Richard Schwarting" <[EMAIL PROTECTED]> writes: > Yes Francisco. This has fixed the issue of being off-centre and such. > > I'll note that, though X displayed correctly, while using it, new > windows would come up simply as white boxes for the first few seconds, > I'm not sure to. As well, when I did open a window or a menu or such, > the entire desktop would freeze up for a few seconds, my cursor not > even moving and not responding to Ctrl-Alt-Fn. After those few > seconds, things would proceed. > > I tried disabling acceleration by setting Option "NoAccel". Now, my > desktop stopped freezing completely, but things still took an unusual > long time to start drawing, and the desktop felt sluggish. Reading > the man page for siliconmotion, I opted to try Option "AccelMethod" > "EXA", and now things are mostly better. Using EXA, there is the odd > glitch when the cursor hovers over a point (a rectangle around it > becomes a green color, for some inexplicable reason). > > Anyway, I'm interested in getting this fixed downstream before the > next set of distro releases so that others who suffer the same problem > won't need to wait 5 months :) What more can I do in regard to this? > Just created distro-level bug reports and point them to this thread? > > Also, I'm curious whether you have a SM720 Lynx3DM handy yourself or > whether you have to do your work via another SM card. Are they > similar enough that driver changes don't usually break support for > just one of the card types? In the future, if there are any changes > you'd be interested to see tested on an Sm720 Lynx3DM, I'd be happy to > help (presuming this tablet hasn't fallen apart first.). I'd make a > piont of testing newer versions of the driver periodically to help > catch issues with this card earlier. Though, I wonder whether I'm the > only person still using Linux on one :) > > Thank you very much. I hope to repay your helpfulness some day, as > you've really made my life a lot easier :) > > Cheers, > Richard Schwarting > > In fact, the only Silicon Motion hardware I've got access to is another SM720 card. I'm not experiencing those problems on it. Would you send a full log? (BTW, could it be related to the great amount of logging that the SMI_DEBUG flag provokes?). > On Thu, Dec 4, 2008 at 06:51, Francisco Jerez <[EMAIL PROTECTED]> wrote: >>> Hello. >>> >>> I'm not sure if that changed anything, but things sort of work. >>> >>> After patching, recompiling, and reinstalling the driver, X would >>> still be off centre. >>> >>> However, I restarted the computer the first time I ran X, everything >>> appeared as I would hope. I then brought it down and back up again, >>> but it was out of centre again. Restarting it a dozen times didn't >>> help. >>> >>> However, I tried putting my computer to sleep and waking it up, and, >>> as with a fresh restart, X displayed correctly again. However, simply >>> switching VTs to a console and back to X make it off again. >>> >>> I've updated the bug[1] with the log file with SMI_DEBUG defined and >>> from a session of (after resuming from suspend): X working, switching >>> to a console, switching back to not having it work. >>> >>> Would it be worthwhile to have me try the driver without the patch >>> again and see whether I can make it work after suspend/resume or a >>> power cycle? >>> >>> Thanks again Francisco. >>> Richard >>> >>> 1. https://bugs.freedesktop.org/show_bug.cgi?id=18816 >>> >> Hello again, >> >> I've done some corrections to the mode setting code (I'm attaching the >> patch). Could you try it out over the last one and tell me if it works? >> >>> On Tue, Dec 2, 2008 at 15:32, Francisco Jerez <[EMAIL PROTECTED]> wrote: > Thank you, again. > > Yes, the MTRR errors do not appear to be fatal. > > Option "UseBIOS" "off" makes a big difference. The screen is no > longer just black, and I can see a background and the moving cursor! > However, it is as though the hsync and vsync are terribly off- as the > display is quite a bit off-centre, wraps around the screen, is > sometimes repeated along the horizontal, and has visible moving scan > lines. > Hi, I think I have reproduced your problem, maybe the offset display is because screen centering is active on server start up. If so, the patch I'm attaching will probably solve it. BTW, I wonder if the UseBIOS option should default to off, with all these laptops with broken bioses. > I have uploaded a copy of my Xorg.0.log using the "UseBIOS" "off" and > using -logverbose 7 to the bug: > https://bugs.freedesktop.org/show_bug.cgi?id=18816 > > I will replace it with one with SMI_DEBUG defined this afternoon (I > didn't have time this morning :D). > > I will also try different combinations of modes and v/hsync, though > I'm wondering whether the offset weird display is actually caused by > incorrectly set values f
Re: Broken X11 After Mandriva Upgrade
I had to rebuild the RPM database since I got an error trying the uninstall. Then when I did the uninstall it said that driver was not installed. So I proceeded to install the suggested version. The install seemed to work fine. Unfortunately, nothing has changed. When I 'startx', I get the following: X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Linux_2.6.24.5-server-2mnb Mandriva Current Operating System: Linux dap002 2.6.22.9-desktop-1mdv #1 SMP Thu Sep 27 04:07:04 CEST 2007 i686 Build Date: 07 August 2008 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Dec 6 17:02:06 2008 (==) Using config file: "/etc/X11/xorg.conf" Using vt 7 (II) Module already built-in (II) Module already built-in xinit: No such file or directory (errno 2): Cannot register with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory SetClientVersion: 0 9 SetGrabKeysState - disabled At this stage, X is running but I cannot start any sessions. It appears to me that what ever process creates that socket is not installed or is not running. I also question the line that says "Using vt 7" rather then saying something about 'i810'. My xorg.conf has the driver set to 'i810'. Is there a way to verify the installation of X11 or to force a reinstall? Now that I have the rpm database rebuilt maybe I need to force a reinstall of all X11. _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
Yes Francisco. This has fixed the issue of being off-centre and such. I'll note that, though X displayed correctly, while using it, new windows would come up simply as white boxes for the first few seconds, I'm not sure to. As well, when I did open a window or a menu or such, the entire desktop would freeze up for a few seconds, my cursor not even moving and not responding to Ctrl-Alt-Fn. After those few seconds, things would proceed. I tried disabling acceleration by setting Option "NoAccel". Now, my desktop stopped freezing completely, but things still took an unusual long time to start drawing, and the desktop felt sluggish. Reading the man page for siliconmotion, I opted to try Option "AccelMethod" "EXA", and now things are mostly better. Using EXA, there is the odd glitch when the cursor hovers over a point (a rectangle around it becomes a green color, for some inexplicable reason). Anyway, I'm interested in getting this fixed downstream before the next set of distro releases so that others who suffer the same problem won't need to wait 5 months :) What more can I do in regard to this? Just created distro-level bug reports and point them to this thread? Also, I'm curious whether you have a SM720 Lynx3DM handy yourself or whether you have to do your work via another SM card. Are they similar enough that driver changes don't usually break support for just one of the card types? In the future, if there are any changes you'd be interested to see tested on an Sm720 Lynx3DM, I'd be happy to help (presuming this tablet hasn't fallen apart first.). I'd make a piont of testing newer versions of the driver periodically to help catch issues with this card earlier. Though, I wonder whether I'm the only person still using Linux on one :) Thank you very much. I hope to repay your helpfulness some day, as you've really made my life a lot easier :) Cheers, Richard Schwarting On Thu, Dec 4, 2008 at 06:51, Francisco Jerez <[EMAIL PROTECTED]> wrote: >> Hello. >> >> I'm not sure if that changed anything, but things sort of work. >> >> After patching, recompiling, and reinstalling the driver, X would >> still be off centre. >> >> However, I restarted the computer the first time I ran X, everything >> appeared as I would hope. I then brought it down and back up again, >> but it was out of centre again. Restarting it a dozen times didn't >> help. >> >> However, I tried putting my computer to sleep and waking it up, and, >> as with a fresh restart, X displayed correctly again. However, simply >> switching VTs to a console and back to X make it off again. >> >> I've updated the bug[1] with the log file with SMI_DEBUG defined and >> from a session of (after resuming from suspend): X working, switching >> to a console, switching back to not having it work. >> >> Would it be worthwhile to have me try the driver without the patch >> again and see whether I can make it work after suspend/resume or a >> power cycle? >> >> Thanks again Francisco. >> Richard >> >> 1. https://bugs.freedesktop.org/show_bug.cgi?id=18816 >> > Hello again, > > I've done some corrections to the mode setting code (I'm attaching the > patch). Could you try it out over the last one and tell me if it works? > >> On Tue, Dec 2, 2008 at 15:32, Francisco Jerez <[EMAIL PROTECTED]> wrote: Thank you, again. Yes, the MTRR errors do not appear to be fatal. Option "UseBIOS" "off" makes a big difference. The screen is no longer just black, and I can see a background and the moving cursor! However, it is as though the hsync and vsync are terribly off- as the display is quite a bit off-centre, wraps around the screen, is sometimes repeated along the horizontal, and has visible moving scan lines. >>> Hi, I think I have reproduced your problem, maybe the offset display is >>> because screen centering is active on server start up. >>> >>> If so, the patch I'm attaching will probably solve it. >>> >>> BTW, I wonder if the UseBIOS option should default to off, with all >>> these laptops with broken bioses. >>> I have uploaded a copy of my Xorg.0.log using the "UseBIOS" "off" and using -logverbose 7 to the bug: https://bugs.freedesktop.org/show_bug.cgi?id=18816 I will replace it with one with SMI_DEBUG defined this afternoon (I didn't have time this morning :D). I will also try different combinations of modes and v/hsync, though I'm wondering whether the offset weird display is actually caused by incorrectly set values for them, as I've tried rates that had worked previously. Cheers, Richard Schwarting On Tue, Dec 2, 2008 at 04:48, Francisco Jerez <[EMAIL PROTECTED]> wrote: > Hi, > > "Richard Schwarting" <[EMAIL PROTECTED]> writes: > >> Thanks for the responses. >> >> == Silicon Motion from git == >> >> Yes Francisco, I've tried the latest code from >> git://anongit.freedeskt
libpciaccess ROM read reads more than advertised
Hi, i noticed the amount of data read by pci_device_linux_sysfs_read_rom is determined by the file size from sysfs, while the rom_size reported to the drivers is calculated using a different algorithm. This leads to invalid memory writes if the file size is greater than the calculated size. Possible patch attached. Regards, Pierre commit daa4187bddda5d22fca7d91eef9790424d738fa6 Author: Pierre Willenbrock <[EMAIL PROTECTED]> Date: Sat Dec 6 01:25:33 2008 +0100 Don't read more data than advertised. diff --git a/src/linux_sysfs.c b/src/linux_sysfs.c index 8c3cf67..46240da 100644 --- a/src/linux_sysfs.c +++ b/src/linux_sysfs.c @@ -337,6 +337,8 @@ pci_device_linux_sysfs_read_rom( struct pci_device * dev, void * buffer ) rom_size = st.st_size; if ( rom_size == 0 ) rom_size = 0x1; +if (rom_size > dev->rom_size) /* don't read more data than advertised. */ + rom_size = dev->rom_size; /* This is a quirky thing on Linux. Even though the ROM and the file * for the ROM in sysfs are read-only, the string "1" must be written to ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
