Re: Problem with RECORD, XInput(2) (and Xnee)
Thanks a lot. That clarified it :) Xnee can now record the device events from Xinput. Some work remains though with the non device events. A basic replay (XTest) of multiple pointers seems to be working as well. .. and about implementing XI2 in RECORD. I'd love to do it, but as most of us currently (or constantly) I am lacking the time to do it. But some fine day. /hesa On 05/25/2010 04:21 AM, Peter Hutterer wrote: On Tue, May 25, 2010 at 12:36:38AM +0200, Henrik Sandklef wrote: hi I am currently implementing support for XInput(2) devices in GNU Xnee, starting out with recording events. Xnee gets copies of events from the X Server (using the RECORD extension). It seems to be a problem in the RECORD extension regarding XI (or XI(2)), but I am not sure and it would be great to get feedback. I'll try to describe the problem as good as I can. --- When reading the XInput spec and the corresponding source code I understand it as one XI2 event is packed into two "normal" events. I started by implementing support for MotionEvents. This worked out rather well. Xnee receives four "normal" events and packs them into two XI2 events (one from the master and one from the slave) and prints them out. I think you may be mixing up XI2 and XI 1.x here. XI 1.x does indeed that. The limitations on event size to 32 bits means only some valuators fit into the first event a flag (highest bit in device-id) in the first event specifies if there are more to come (the others are of type DeviceValuator). Xlib packs those together into one event. XI2 uses GenericEvents exclusively which work very different, all of type 35 and you need to watch the extension field and -more importantly- the lenght field because you may need to pull down more data. See the event cookie mechanisms in Xlib. Having said that, I don't think RECORD writes XI2 events onto the wire at the moment, so that point is moot. When moving a pointer one pixel Xnee gets (event, detail): 83 detail=0 78 detail=9 83 detail=0 78 detail=13 The event base for XI is 78, so it looks ok to me. The detail is set to the deviceid of the input device (when not 0). 83 is the motion event then, 78 is the DeviceValuator event, the above are two separate motion events. Look up the protocol spec for DeviceValuator, IIRC it's described there how the events are squashed together. if you have a large number of valuators, you'd get 83 78 78 78 83 78 78 78, etc. But when adding support for ButtonPress and ButtonRelease I don't get the 4 events for every press (or release). And the detail is always set to the number of the button pressed. When pressing a button Xnee gets (event, detail): 81 detail=1 81 detail=1 82 detail=2 82 detail=2 two button presses, two button releases. Likely because you're seeing the master and the slave device events - they should have different deviceids. we don't send valuators down after those events because the drivers usually send motion events before the button events, so the actual button events don't contain valuator data and hence no trailing DeviceValuators. When reading the source code of XInputWireToEvent (libXi/src/XExtInt.c) it looks as if the client side of XI does pack two events together to one. Since RECORD doesn't give Xnee normal client side events (as normal apps get from client libs) but rather "limited" copies directly from the server, it seems to be something odd in the RECORD extension (or with my code). Most of my tests are done using swinput (Linux module) with support for 8 input devices, but I've tested with real devices as well. you can freely use software-emulated devices, there's no difference at this level anymore. so yeah, you're close but you need to distinguish between master and slave devices (or not, depending on what's needed). And as I said above, you're working against XI 1.5 here. Though updating RECORD to transmit XI2 events as well wouldn't be a bad project if you're interested. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: h...@sandklef.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
i915 interlaced display, again
Hi,
Now that the non-KMS support is gone, the following patches implement
interlaced mode display on i915 and similar hardware.
Tested on i915 + analog VGA, it would be worth checking if newer chips
(and which ones) still support interlaced mode.
The patches don't change the clock limits (minimums), i.e. they alone
won't make it output 720x576 PAL no 720x480 NTSC, but they will work
with modes like 1080i etc. (including GLX and textured Xvideo, not sure
about the overlay).
Comments?
For the kernel (against v2.6.34 ATM):
Signed-off-by: Krzysztof Halasa
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -545,7 +545,7 @@ void intel_crt_init(struct drm_device *dev)
(1 << INTEL_ANALOG_CLONE_BIT) |
(1 << INTEL_SDVO_LVDS_CLONE_BIT);
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
- connector->interlace_allowed = 0;
+ connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
drm_encoder_helper_add(&intel_encoder->enc, &intel_crt_helper_funcs);
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2122,6 +2123,8 @@ static bool intel_crtc_mode_fixup(struct drm_crtc *crtc,
if (mode->clock * 3 > 27000 * 4)
return MODE_CLOCK_HIGH;
}
+
+ drm_mode_set_crtcinfo(adjusted_mode, 0);
return true;
}
@@ -3377,6 +3380,18 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
}
}
+ if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ pipeconf |= PIPECONF_INTERLACE_W_FIELD_INDICATION;
+ /* the chip adds 2 halflines automatically */
+ adjusted_mode->crtc_vdisplay -= 1;
+ adjusted_mode->crtc_vtotal -= 1;
+ adjusted_mode->crtc_vblank_start -= 1;
+ adjusted_mode->crtc_vblank_end -= 1;
+ adjusted_mode->crtc_vsync_end -= 1;
+ adjusted_mode->crtc_vsync_start -= 1;
+ } else
+ pipeconf &= ~PIPECONF_INTERLACE_W_FIELD_INDICATION; /*
progressive */
+
I915_WRITE(htot_reg, (adjusted_mode->crtc_hdisplay - 1) |
((adjusted_mode->crtc_htotal - 1) << 16));
I915_WRITE(hblank_reg, (adjusted_mode->crtc_hblank_start - 1) |
Simple, isn't it?
The driver, against 2.11.0 (Fedora-13 SRPM to be exact). I'm not sure if
the way to check for interlaced mode is the best one:
--- a/src/drmmode_display.c 2010-05-25 13:15:23.629362630 +0200
+++ b/src/drmmode_display.c 2010-05-18 16:23:16.097228921 +0200
@@ -1272,6 +1272,7 @@
output->possible_crtcs = kencoder->possible_crtcs;
output->possible_clones = kencoder->possible_clones;
+ output->interlaceAllowed = TRUE;
return;
}
--- a/src/i830_dri.c2010-05-25 13:15:23.629362630 +0200
+++ b/src/i830_dri.c2010-05-25 18:04:39.565361948 +0200
@@ -348,6 +348,12 @@
event = MI_WAIT_FOR_PIPEB_SVBLANK;
}
+ if (scrn->currentMode->Flags & V_INTERLACE) {
+ /* DSL counts field lines */
+ y1 /= 2;
+ y2 /= 2;
+ }
+
BEGIN_BATCH(5);
/*
* The documentation says that the LOAD_SCAN_LINES
--- a/src/i830_video.c 2010-03-18 18:13:36.0 +0100
+++ b/src/i830_video.c 2010-05-25 18:05:05.892486453 +0200
@@ -1308,6 +1308,12 @@
pixman_f_transform_bounds(&crtc->f_framebuffer_to_crtc,
&box_in_crtc_coordinates);
+ if (scrn->currentMode->Flags & V_INTERLACE) {
+ /* DSL counts field lines */
+ box_in_crtc_coordinates.y1 /= 2;
+ box_in_crtc_coordinates.y2 /= 2;
+ }
+
BEGIN_BATCH(5);
/* The documentation says that the LOAD_SCAN_LINES command
* always comes in pairs. Don't ask me why. */
--
Krzysztof Halasa
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Current tinderbox regression (xf86-video-chips)
On Tue, May 25, 2010 at 01:49:58PM +0200, ext Chris Ball wrote: > http://tinderbox.x.org/builds/2010-05-25-0012/logs/xf86-video-chips/#build > > ct_driver.c: In function 'CHIPSAvailableOptions': > ct_driver.c:790: error: 'BUS_ISA' undeclared (first use in this function) > > http://cgit.freedesktop.org/xorg/xserver/commit/?id=47df5a489ea69a68e753367423bfbe8830521f4e Just fixed on the driver side. Thanks for pointing out Chris! Tiago ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Current tinderbox regression (xf86-video-chips)
http://tinderbox.x.org/builds/2010-05-25-0012/logs/xf86-video-chips/#build ct_driver.c: In function 'CHIPSAvailableOptions': ct_driver.c:790: error: 'BUS_ISA' undeclared (first use in this function) http://cgit.freedesktop.org/xorg/xserver/commit/?id=47df5a489ea69a68e753367423bfbe8830521f4e -- Chris Ball One Laptop Per Child ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
