/usr/share/X11/locale/*/Compose
Who's in charge of that? It doesn't seem to be xkeyboard-config; is it xorg? I ask because we now have a keyboard map for the APL programming language, and it will need its own special compose sequences for the Unicode APL symbols. Thanks, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: /usr/share/X11/locale/*/Compose
On Tue, 23 Jun 2009, Timothy S. Nelson wrote:
Who's in charge of that? It doesn't seem to be xkeyboard-config; is
it xorg? I ask because we now have a keyboard map for the APL programming
language, and it will need its own special compose sequences for the Unicode
APL symbols.
Nevermind, and sorry to have bothered everyone -- I found that I asked
this question on IRC some time ago. For the mailing list archive, it went
like this:
[20:25] wayland76 Who's responsible for the xorg locale files?
[20:25] wayland76 eg. /usr/share/X11/locale/en_US.UTF-8/Compose on my Fedora
system?
[20:27] wayland76 ie. is it the xorg people, or xkeyboard-config, or someone
else?
[20:29] jcristau wayland76: xorg
[20:30] wayland76 ok, thanks
[20:31] jcristau (it's the 'Lib/Xlib (data)' component in bugzilla)
[20:31] wayland76 Is it possible to make those files go include otherfile
?
[20:31] wayland76 ok, thanks,
[20:32] wayland76 Or rather, let me ask a more general question -- If I want
to add combinations that do other symbols, is there a way to do that other
than editing the locale Compose file?
[20:34] jcristau include otherfile works, yes
[20:34] jcristau and for local changes you can edit ~/.XCompose
[20:36] jcristau ('include %L' in ~/.XCompose will give you the standards
combinations, and then you can add yours)
[20:36] jcristau standard, even
Sorry again...
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
XFixesFetchRegion() crashes app
My application attaches a XFixes created reactangle to a window.
Therefore it does a XOpenDisplay() + XFixesCreateRegion() +
XCloseDisplay() inside one short function and done.
After the above outlined function resturns a call to XFixesFetchRegion()
from a outside observer forces the application to quit:
PropertyNotify : _NET_COLOR_REGIONSv 679x580+642+245 2
X Error of failed request: 179
Major opcode of failed request: 155 (XFIXES)
Minor opcode of failed request: 19 (XFixesFetchRegion)
Serial number of failed request: 7927
Current serial number in output stream: 7927
Any idea how to avoid a quit from XFixesFetchRegion()? A error message
would be enough. A exit in not acceptable to the application.
A minimal example application source code is attached.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
/* !cc -Wall -g -o test_XFixes test_XFixes.c -lXfixes -lX11 */
#include X11/Xlib.h
#include X11/extensions/Xfixes.h
#include stdio.h
int main(int argc, char * argv[])
{
Display * display = XOpenDisplay(0);
XRectangle rec[2] = { { 0,0,0,0 }, { 0,0,0,0 } },
* rect = 0;
int nRect = 0;
XserverRegion reg = 0;
rec[0].x = 10;
rec[0].y = 20;
rec[0].width = 30;
rec[0].height = 40;
reg = XFixesCreateRegion( display, rec, 1);
rect = XFixesFetchRegion( display, reg, nRect );
if(!nRect)
printf( no region to be found %d\n, (int)reg );
else
printf( rect found[%d]: %dx%d+%d+%d\n, (int)reg,
rect-width, rect-height, rect-x, rect-y );
XCloseDisplay( display ); display = 0;
printf( close display\n\n );
/* reopen */
printf( reopening display and fetching the same region[%d]\n\n, (int)reg );
display = XOpenDisplay(0);
nRect = 0;
rect = XFixesFetchRegion( display, reg, nRect );
if(!nRect)
printf( no region to be found %d\n, (int)reg );
else
printf( rect found: %dx%d+%d+%d\n,
rect-width, rect-height, rect-x, rect-y );
XCloseDisplay( display ); display = 0;
return 0;
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Common sense (and the fact that the error says BadRegion here) suggest that reg = XFixesCreateRegion( display, rec, 1); This region number is no longer valid after you close the display. Doing this a 2nd time after setting nRect = 0 will fix it. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How to configure dual head display using geode or vesa drivers
Hai! I am using Geode LX video display. My system works fine with both generic vesa and geode drivers. I want to use another system with same graphics card as extended monitor ( I want single big display spreaded over two monitors). I tried following xorg.conf but I could not get desired display. I was getting just clone display of my system on extended monitor. How to configure dual head display using geode or vesa driver? Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 Screen 1 Screen1 RightOf Screen0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard Option Xinerama on EndSection Section Files ModulePath /usr/lib/X11/modules FontPath /usr/share/fonts/X11/misc/ EndSection Section Module Load extmod Load dbe Load record Load freetype EndSection Section InputDevice Identifier Keyboard0 Driver kbd Option AutoRepeat 400 30 EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameLCD Panel 1280x1024 EndSection Section Monitor Identifier Monitor1 VendorName Monitor Vendor ModelNameLCD Panel 1280x1024 EndSection Section Device Identifier Card0 Driver geode VendorName Advanced Micro Devices [AMD] BoardName Geode LX Video BusID PCI:0:1:1 Screen 0 Option PanelGeometry 1280x1024 EndSection Section Device Identifier Card1 Driver geode VendorName Advanced Micro Devices [AMD] BoardName Geode LX Video BusID PCI:0:1:1 Screen 1 Option PanelGeometry 1280x1024 EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth24 SubSection Display Viewport 0 0 Depth 1 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 4 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 8 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 15 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 16 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 24 Modes 1280x1024 EndSubSection EndSection Section Screen Identifier Screen1 Device Card1 MonitorMonitor1 DefaultDepth24 SubSection Display Viewport 0 0 Depth 1 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 4 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 8 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 15 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 16 Modes 1280x1024 EndSubSection SubSection Display Viewport 0 0 Depth 24 Modes 1280x1024 EndSubSection EndSection Section ServerFlags Option Xinerama ON EndSection ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Am 23.06.09, 11:35 +0200 schrieb Maarten Maathuis: Common sense (and the fact that the error says BadRegion here) suggest that reg = XFixesCreateRegion( display, rec, 1); This region number is no longer valid after you close the display. Doing this a 2nd time after setting nRect = 0 will fix it. Other than I expected XFixesCreateRegion()/XFixesFetchRegion() is not useful for inter application communication. Thanks for the quick answere. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Please don't think i know what you are actually trying to do, i solved this like you would a puzzle. First guess happened to work. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (pixman, ppc64)
On Mon, 2009-06-22 at 23:53 -0400, Chris Ball wrote:
http://tinderbox.x.org/builds/2009-06-23-0002/logs/pixman/#build
pixman-fast-path.c: In function 'Store24':
pixman-fast-path.c:69: error: invalid operands to binary * (have 'int'
and 'uint8_t *')
The patch below fixes this.
diff --git a/pixman/pixman-fast-path.c b/pixman/pixman-fast-path.c
index 48c9a87..7d3f0c0 100644
--- a/pixman/pixman-fast-path.c
+++ b/pixman/pixman-fast-path.c
@@ -65,7 +65,7 @@ Store24 (uint8_t *a, uint32_t v)
else
{
#ifdef WORDS_BIGENDIAN
- *(uint16_t *)a = (uint16_t)(v 8)
+ *(uint16_t *)a = (uint16_t)(v 8);
*(a + 2) = (uint8_t)v;
#else
*(uint16_t *)a = (uint16_t)v;
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
And this region is some property of the root window? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Kai-Uwe Behrmann k...@gmx.de writes: My application attaches a XFixes created reactangle to a window. Therefore it does a XOpenDisplay() + XFixesCreateRegion() + XCloseDisplay() inside one short function and done. After the above outlined function resturns a call to XFixesFetchRegion() from a outside observer forces the application to quit: PropertyNotify : _NET_COLOR_REGIONSv 679x580+642+245 2 X Error of failed request: 179 Major opcode of failed request: 155 (XFIXES) Minor opcode of failed request: 19 (XFixesFetchRegion) Serial number of failed request: 7927 Current serial number in output stream: 7927 Any idea how to avoid a quit from XFixesFetchRegion()? A error message would be enough. A exit in not acceptable to the application. My memory is rather unclear on this point, but if the default error handler exits the program, the solution could be to install your own error handler with XSetErrorHandler() eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: unexpected phenomenon on XV texture adapter with no scaling
On 22.06.2009 19:11, Krzysztof Halasa wrote: Roland Scheidegger srol...@tungstengraphics.com writes: With a very quick look at the r600 code, I suggest trying out the attached patch to test my theory about half pixel offsets in hardware. This could mess though with EXA acceleration, so if you see a bit odd corruption don't be surprised :-). I can now confirm this patch, applied to current Fedora 11 xorg-x11-drv-ati-6.12.2-14 driver, fixes this Xv issue on RV6xx. I can't see any EXA corruption. Thanks a lot. I guess it should be aplied to the repository? I think it's probably the right thing to do, but I'm a bit worried there might be side effects in other parts (composite), though it's possible it would be actually more correct there too. I've never really looked into the r6xx side of things in the driver, so I'd like some opinion from someone more familiar with that code. Alex? Roland --- a/src/r6xx_accel.c +++ b/src/r6xx_accel.c @@ -974,7 +974,7 @@ set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib) EREG(ib, PA_SU_POLY_OFFSET_FRONT_OFFSET, 0); EREG(ib, PA_SU_LINE_CNTL, (8 PA_SU_LINE_CNTL__WIDTH_shift)); /* Line width 1 pixel */ -EREG(ib, PA_SU_VTX_CNTL, ((2 PA_SU_VTX_CNTL__ROUND_MODE_shift) | +EREG(ib, PA_SU_VTX_CNTL, ((2 PA_SU_VTX_CNTL__ROUND_MODE_shift) | PIX_CENTER_bit | (5 QUANT_MODE_shift))); /* Round to Even, fixed point 1/256 */ EREG(ib, PA_SU_POLY_OFFSET_CLAMP, 0); ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Am 23.06.09, 13:10 +0200 schrieb Eirik Byrkjeflot Anonsen: Kai-Uwe Behrmann k...@gmx.de writes: Any idea how to avoid a quit from XFixesFetchRegion()? A error message would be enough. A exit in not acceptable to the application. My memory is rather unclear on this point, but if the default error handler exits the program, the solution could be to install your own error handler with XSetErrorHandler() man XSetErrorHandler is the right pointer. Thanks. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Paul Menzel paulepan...@users.sourceforge.net writes: I am no expert and do not know if it has anything to do with your “problem”, but have you heard of the FRC patches [1] yet? I put Thomas, the author of the patches, to receivers of this message. Thanks for the pointer. It's seems those patches are a bit different functionality, what I'm going to implement is the BFF/TFF(/progressive) interface at XVideo and DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 03:54:03PM +0200, Krzysztof Halasa wrote: DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. with a slight modification the patches can output BFF or TFF. But I'm living in PAL land so I use TFF only ATM. going to implement is the BFF/TFF(/progressive) interface at XVideo and what do you mean with progressive here? Do you mean 2 interlaced fields in weaved format? The vga-sync-fields patches effectively use these 2 weaved fields of softdecoder output and forward these directly to VGA/DVI output. To keep synchronicity between stream and video timing the output line frequency is continuously trimmed in very small steps. This works very well even for live-TV where you must adopt exactly the stream clock delivered by the TV station. Trimming the graphics card video timing ensures that the weaved fields always appear at the right time in the double buffer of graphics card. Video output is interlaced. It's the task of the display to take care of deinterlacing (if needed). This relieves the PC from CPU intensive deinterlacing. So the patches work very well with Asus EEE 701 or Intel D945GSEJT. DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. moving the sync point by 20ms yields in reversed field order output Cheers Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: override_redirect
On Jun 23, 2009, at 05:47, Bedő Sándor wrote: Hi! This will be much more an xlib question than an xorg one, so please forgive me! Is there a way in a window manager to force all the other clients to set override_redirect to False in their XSetWindowAttributes structures on top level windows? (I'm looking for something like AttributeChangeRequest event or so, where I can change this to False...) I know it sounds silly, but I really need this. No, there's no way to force some other program to do what you want. Most top-level windows should not be override-redirect. The main uses for o-r are menus and tooltips. If an application is setting o-r on a top level window, that's a bug, IMO, but they're free to do it. Additionally, you need this. Please explain why you think you need it, and we'll try to help you come up with a different approach. --Jeremy ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: xf86-video-intel: unexpected phenomenon on XV texture adapter with no scaling
This works just fine on my system. I added the info on the xorg bugzilla so that Intel folks can put it into the driver. Many thanks ! Hugo Jacques -Original Message- From: Krzysztof Halasa [mailto:k...@pm.waw.pl] Sent: Monday, June 22, 2009 15:59 To: Roland Scheidegger Cc: Jacques, Hugo; xorg@lists.freedesktop.org Subject: Re: xf86-video-intel: unexpected phenomenon on XV texture adapter with no scaling Krzysztof Halasa k...@pm.waw.pl writes: It seems that the fix to i915 is: diff --git a/src/i915_video.c b/src/i915_video.c index 1ef58ac..3b4247c 100644 --- a/src/i915_video.c +++ b/src/i915_video.c @@ -136,8 +136,8 @@ I915DisplayVideoTextured(ScrnInfoPtr pScrn, I830PortPrivPtr pPriv, int id, format = COLR_BUF_ARGB | DEPTH_FRMT_24_FIXED_8_OTHER; OUT_BATCH(LOD_PRECLAMP_OGL | -DSTORG_HORT_BIAS(0x80) | -DSTORG_VERT_BIAS(0x80) | +DSTORG_HORT_BIAS(0x8) | +DSTORG_VERT_BIAS(0x8) | format); /* front buffer, pitch, offset */ I think it's safe to commit. Seems like a simple mistake, those fields in that variable seem to be 4-bits wide. Fixes the problem. -- Krzysztof Halasa This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: with a slight modification the patches can output BFF or TFF. But I'm living in PAL land so I use TFF only ATM. I'm here as well but I routinely use PAL MPEG2 (DVD) with BFF encoding (originating as DV which is always BFF, I could of course shift the audio and reverse fields but it creates some minor additional problems). going to implement is the BFF/TFF(/progressive) interface at XVideo and what do you mean with progressive here? Do you mean 2 interlaced fields in weaved format? Progressive video playback on interlaced display. This means the driver is free to sync to either field (for example, to the previously selected one). The vga-sync-fields patches effectively use these 2 weaved fields of softdecoder output and forward these directly to VGA/DVI output. To keep synchronicity between stream and video timing the output line frequency is continuously trimmed in very small steps. This works very well even for live-TV where you must adopt exactly the stream clock delivered by the TV station. Right. This is well beyond my needs. DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. moving the sync point by 20ms yields in reversed field order output Ah... But there is a simple interrupt-based way. And it doesn't depend on the timings, the card signals end of each field. You may want to see intelfb for details, I was using fb because the X playback was unusable. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Mon, Jun 22, 2009 at 09:56:20PM +0200, Krzysztof Halasa wrote: My assumption (please correct if wrong): - it requires interlaced display mode (i830+: practically completed). sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics - sync events for TFF and BFF are signaled by interrupts. For progressive video (with interlaced display mode, of course) we can not necessarily by driver interrupts. In [1] (intel portion of vga-sync-fields patch) I simply peek some registers (DOVSTA and PIPEA_DSL) directly within the Xserver to determine the actual line + field position of CRT controller at any time. In [2] (radeon portion of the patch) I do the same with radeon graphics. A small DRM-driver patch there is only needed to dynamically alter video output timing. You are right: for i810 some field related overlay regs must be reprogrammed during vertical retrace interrupts. This is no longer true for i9xx architecture. 2 weaved fields are processed there with no driver (interrupt) intervention. - Thomas [1] http://www.easy-vdr.de/git?p=frc.git/.git;a=blob;f=patches/xv-intel.patch;h=b54655a6d6473f55b49fac759f4afc77c101d69f;hb=20810204a85917449096a5fbba65d996c0a1ac2c [2] http://www.easy-vdr.de/git?p=frc.git/.git;a=blob;f=patches/xv-radeon.patch;h=8c6ee3f199f70364c91057c634dfbf864c3db656;hb=20810204a85917449096a5fbba65d996c0a1ac2c ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-chips driver support for multiple heads CPU to Screen Color Expansion
Hello, I have been able to modify the driver to support independent images on each head for the CT 69030. I will make it available to all when complete. I do not intend to check this in for a few reasons. 1) I didn't like the way it was written with respect to formatting and with respect to the number of devices it supports. 2) I only needed to support one device, so I have mostly stripped out any code that did not compile for my platform. Trying to cram and learn enough of xserver and driver code into one several week project was enough of a task. 3) These changes only work on the X7.3 release. I don't need it to work beyond that, even for the target I have. 4) The code only supported mirrored data from one head to the other, it also used IO space that get's mapped to PCI/IO space to communicate with the driver and partly uses memory registers. My product has two 69030 controllers, so only memory mapped I/O is allowed. 5) I made major changes to the way registers are restored, and have no way of testing against any other platforms. Now, I have problems with CPU to Screen Color Expansion. When the XAA architecture uses color expansion registers to transfer data to the graphics memory, it is not accomplished through the frame buffer, but through a 64K bit of PCI bus memory. I have a PPC processor, so I have to worry about byte swapping, and all data that is Blit'd out he 64K addresses have an odd swapping going on. It is hard to describe, but if you start xfontsel and pick a family of nice 8x8 fixed pitch font and look at the display, it read BADCFE... This has to be a swapping problem somewhere, so I was wondering if anyone had insight on the color expansion notion in a PPC environment. Thanks, Donald x...@kayser.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: RFC: Xv field order
Krzysztof Halasa k...@pm.waw.pl writes: I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? What video encoder are you planning to use for the TV out? I am using a Chrontel 7022 on a SDVO/ADD2 card driven by a 945G chipset to output on a composite coax cable. When sending it 720x480 frames (I work in NTSC) I keep getting scaling artifacts (that are not caused by XV texturing this time:). If I could get rid of that scaling artifact, I think that I could send it the 720x480 frames consisting of the two weaved fields and get a decent interlaced video quality (although timing from frame to frame might still be an issue) Hugo Jacques This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with resumed suspend: Work (dual/external heads) = Home (built in laptop display)
Hi Jamie, What's your hardware? Which video driver do you use? I've got a very similar problem, except that mostly only either the internal or the external display is deactivated after resume. Also, the problem can be reproduced without actually switching monitors (like in your case with home/work). Can you try again by just suspending and resuming without disconnecting the external monitor? Anyway, here is my bugreport: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/352708 Best regards, Andreas On Thu, 2009-06-18 at 01:08 -0400, Jamie Jackson wrote: (Ubuntu 9.04) At work, I've got dual head, external monitors (VGA, TDMS-1). If I suspend there, and resume at home (using only built-in LVDS), I get a black screen. I have similar problems when going in reverse. The only way I've been able to recover is via SSH and xrandr, however, my home = work xrandr process is haphazard. While I can usually get it to work, I can only get enough to give me a panel (on the wrong screen, the VGA) to get to the gnome display config gui (where I can finish the proper config, getting the panel on the main TDMS-1, and the auxiliary display on the smaller VGA). When I need to resume at home, I usually bag it, and just hard reset. I've got a few questions: 1. Is there a way to get X to roam better (be smarter about detecting and using displays on resume)? 2. Alternatively, is there some xrandr sequence I can use that makes the home = work transition less awkward? 3. Also, alternatively, what's the sequence for the work = home transition? (This one's a bit of a pain, because I've got to jump through some hoops to SSH in at home, but if I had a sequence, I could script it, and then maybe blindly run my script from a TTY.) Thanks, Jamie ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. Aaa, right, that may be so. I meant the traditional i830 driver (as opposed to i810), now it's named intel and the DRM is i915. In fact I'm not really interested in pre-915 chips. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics Come on, playback of interlaced video only makes sense with vertically unscaled display. Otherwise you have to deinterlace first and this is hardly usable (except for maybe 1:2 scaling when you can just strip every other line to get progressive video). It doesn't depend on the chip. Well, obviously there is another possibility, you can double the frame rate - I guess not something we can do here (TV sets do that internally). not necessarily by driver interrupts. In [1] (intel portion of vga-sync-fields patch) I simply peek some registers (DOVSTA and PIPEA_DSL) directly within the Xserver to determine the actual line + field position of CRT controller at any time. Yes, I realize you can do it this way. But the chip can do it in hardware. IRQ driven, faster and completely reliable. The code already does it for progressive display + textured video. I've been using interrupt-driver frame sync (with selectable TFF/BFF - though without textured video) for almost 2 years and it's simple, fast and reliable - even with the CPU doing all the work. I wonder... Can your current code support textured video? Multiple video windows? Don't you have reliability problems, caused by the 20 ms sleep taking longer than requested (due to lack of RT scheduling)? You are right: for i810 some field related overlay regs must be reprogrammed during vertical retrace interrupts. I didn't say that. Actually I don't know about i810. This is no longer true for i9xx architecture. 2 weaved fields are processed there with no driver (interrupt) intervention. Consider two video windows, one is BFF and the other one TFF. You have to sync after each field. Of course, each window will get sync events only every complete frame, but they will be a field apart. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Come on, playback of interlaced video only makes sense with vertically unscaled display. Otherwise you have to deinterlace first and this is hardly usable (except for maybe 1:2 scaling when you can just strip every the newer type intel chips do that transparently in hardware. I have not found documentation about how they exactly handle this (by scaling each field independently or by deinterlacing?). But for watching 16:9 material on an 4:3 TV it's a very useful feature. Picture quality is still very good. It doesn't depend on the chip. yes it does. i815 chips and radeon pre-avivo chips can't scale interlaced material vertically. But i9xx chips can do. I wonder... Can your current code support textured video? Multiple video windows? Don't you have reliability problems, caused by the 20 ms sleep taking longer than requested (due to lack of RT scheduling)? no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. The stream clock is calculated within xine-lib (in my case). I built extensive debug tools showing any reliability problems. If you aren't running number crunching processes on the machine whilst watchin TV there are no problems at all. On 2.6.26 or newer kernels I need not alter scheduling policies. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. Aaa, right, that may be so. I meant the traditional i830 driver (as opposed to i810), now it's named intel and the DRM is i915. In fact I'm not really interested in pre-915 chips. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Applying patch for bug 22383
On Mon, Jun 22, 2009 at 9:46 PM, Mike.lifeguardmikelifegu...@fastmail.fm wrote: For bug 22383 (X server stuck in infinite loop on laptop lid close), Jesse Barnes has asked to try applying a very simple patch. However, I don't know how to do that - I've only used packaged code from Ubuntu and/or from various PPAs. Is there a how-to on x.org somewhere I haven't found, or would someone be able to give me some pointers? The patch in bug 22383 is for the DDX so that should be fairly simple to try out. How to apply a patch to a Debian/Ubuntu package (xserver-xorg-video-intel in your case) is explained on https://wiki.ubuntu.com/XorgOnTheEdge HTH, Tormod ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: RFC: Xv field order
-Original Message- From: Krzysztof Halasa [mailto:k...@pm.waw.pl] Sent: Tuesday, June 23, 2009 14:59 To: Jacques, Hugo Cc: xorg@lists.freedesktop.org Subject: Re: RFC: Xv field order Jacques, Hugo hugo.jacq...@verint.com writes: What video encoder are you planning to use for the TV out? At this time I'm using internal RGB VGA. But I'll also personally need an SDVO DVI-D (on-board Chrontel chip). I am using a Chrontel 7022 on a SDVO/ADD2 card driven by a 945G chipset to output on a composite coax cable. When sending it 720x480 frames (I work in NTSC) I keep getting scaling artifacts (that are not caused by XV texturing this time:). If I could get rid of that scaling artifact, I think that I could send it the 720x480 frames consisting of the two weaved fields and get a decent interlaced video quality (although timing from frame to frame might still be an issue) I guess it's Chrontel chip scaling it. Unfortunately the docs don't seem to be public, are they? I don't think they are. I might be wrong. Hugo This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä syrj...@sci.fi writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Well, correct. Is something (hardware, drivers) capable of doing that? It would mostly make sense with small reduction (like 576-480), right? -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: the newer type intel chips do that transparently in hardware. I have not found documentation about how they exactly handle this (by scaling each field independently or by deinterlacing?). Ah, I didn't know this. Is it supported by the textured video? Overlay only? But for watching 16:9 material on an 4:3 TV it's a very useful feature. Picture quality is still very good. Or at least the best we can do. Sure. My TV monitor has different modes (16/9, 14/9, 4/3 and so on) so I haven't though about it, but it's clearly interesting for displaying many video windows simultaneously (thumbnails). no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. Sure, I OTOH work with non-live data. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 10:10:18PM +0200, Krzysztof Halasa wrote: Ville Syrjälä syrj...@sci.fi writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Well, correct. Is something (hardware, drivers) capable of doing that? Any hardware with a decent texture unit (or scaler which writes the results to the framebuffer) should be enough. Also some hardware has video overlays which can do it too (OMAP3 is one example). I don't know if any Xorg driver can do it, but DirectFB's matrox driver supports field based scaling. It uses the texture unit. It would mostly make sense with small reduction (like 576-480), right? The scaling ratio should be irrelevant. The fields are basically independent pictures so you can scale them how much you like. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä wrote: On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Even with scaling, it's not a great idea. Interlacing is a psychovisual hack, designed to make use of your eye's motion-compensation and spatiotemporal interpolation systems. It only works if the scan lines not present in each frame are black, because your persistence of vision will fill in the black lines with the correctly motion-compensated contents of the previous frame. If you scale each field to fill the frame, you will perceive significant flicker and blurring of fine detail. The only way to reproduce the interlace effect correctly is to leave half the lines black in each frame. If you are scaling, this is basically impossible, unless you are scaling up by a factor of at least 2. A good deinterlacer is a much more general solution. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 04:48:25PM -0400, Benjamin M. Schwartz wrote: Ville Syrjälä wrote: On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Even with scaling, it's not a great idea. Interlacing is a psychovisual hack, designed to make use of your eye's motion-compensation and spatiotemporal interpolation systems. It only works if the scan lines not present in each frame are black, because your persistence of vision will fill in the black lines with the correctly motion-compensated contents of the previous frame. Sounds like you're thinking of bob deinterlacing which this is not. The output will still be interlaced with black scanlines and all. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[Announce] X Developers' Conference 2009 (September 28-30)
A reminder that this year's X Developer's Conference is now just 3 months away, but the wiki pages for attendees and talks are still bare. If you're planning on attending, please add yourself to the attendees wiki. If you've got something to talk about, please add it to the program wiki page. For these pages, and further details (some of which is copied below), see: http://xorg.freedesktop.org/wiki/Events/XDC2009 - The 2009 X Developers' Conference[1] will be held at Portland State University (PSU) in Portland, Oregon, from Monday September 28 through Wednesday September 30. PSU is within walking distance of Portland's downtown area and a wide variety of dining, lodging, and public transportation options. The conference is scheduled to follow directly after Linux Plumbers Conference 2009[2] so that people attending both LPC and XDC can do that with a single trip. The conference will be held at the University Place[3] hotel and conference center on the edge of the PSU campus. We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. Attendance is free, but you must register beforehand, by putting your name on the Attendees page. We encourage attendees to stay at the conference hotel (University Place[3]) for convenience. We have initially reserved a block of 20 rooms for the conference, (so let them know you're with the conference when making a reservation). We will attempt to increase that block size as needed, (so please make your reservation as early as possible). [1] XDC 2009: http://xorg.freedesktop.org/wiki/Events/XDC2009 [2] LPC 2009: http://linuxplumbersconf.org/2009/ [3] University Place: http://cegs.pdx.edu/stay/upl/ signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä wrote: Not true if you can scale the fields independently ... Sounds like you're thinking of bob deinterlacing which this is not. The output will still be interlaced with black scanlines and all. True, but even if you're scaling output to a truly interlaced display, scaling a single field will not give you correct spatial behavior. You can think of this is as a frequency-domain aliasing problem in the vertical direction, if you like. The best solution would still be to use a fancy motion-search deinterlacer, and then throw away half the output lines. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 10:19:25PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Ah, I didn't know this. Is it supported by the textured video? Overlay only? I haven't tried textured video since a while because this had bad tearing effects at the time when I started my vga-sync-fields project. This may have changed meanwhile. Scaling interlaced material vertically is supported by at least overlay video on i9xx chips. Maybe somebody can roughly tell how this scaling feature has been realized for intel i9xx series hardware? Would be very interesting. I haven't found any documentation about that yet. no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. Sure, I OTOH work with non-live data. right, when playing non-live data VGA output timing needs not to be synced to an external signal. But for live-TV it's crucial if you don't want to lose fields/frames. The more I'm wondering there still does not exist any other solution to that problem except my vga-sync-fields patch. Even vdpau does still NOT sync video timing to an external clock source (e.g. PTS dictated by a TV station). Which means that even vdpau loses/doubles fields/frames when watching live-TV. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
