[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x-display-pixel-width/height inconsistency
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: x-display-pixel-width/height inconsistency |
Date: |
Thu, 02 May 2013 13:09:45 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Wed, 1 May 2013 11:58:15 +0200, Jan Djärv <address@hidden> said:
>> This guess was not right. GDK rejects XRandR in Xquartz and uses
>> Xinerama instead. The distinction is made by comparing the output
>> name with "default".
>>
>> in init_randr13 (gdkscreen-x11.c):
>>
>> XRROutputInfo *output =
>> XRRGetOutputInfo (dpy, resources, resources->outputs[i]);
>>
>> /* Non RandR1.2 X driver have output name "default" */
>> randr12_compat |= !g_strcmp0 (output->name, "default");
> I did not know that. I've made adjustments for this in the patch, tested on
> XQuartz which indeed does not seem to have a 1.2-compatible driver. Strange
> that.
> I also added name and source (the latter mostly for debugging) to the Lisp
> structure returned.
> I also check for XRRGetScreenResourcesCurrent in configure as that is a 1.3
> version function.
I tried the patch for Xaw build with XQuartz 2.7.4 on OSX 10.8, and it
hit the following assertion failure:
src/xfns.c:3989: Emacs fatal error: assertion failed: 0 <= (i) && (i) < ASIZE
(monitor_frames)
3981 FOR_EACH_FRAME (rest, frame)
3982 {
3983 struct frame *f = XFRAME (frame);
3984
3985 if (FRAME_X_P (f) && FRAME_X_DISPLAY_INFO (f) == dpyinfo
3986 && !EQ (frame, tip_frame))
3987 {
3988 i = x_get_monitor_for_frame (f, monitors, n_monitors);
3989 ASET (monitor_frames, i, Fcons (frame, AREF (monitor_frames,
i)));
3990 }
3991 }
This is because XRRGetScreenResourcesCurrent returns the following
bogus value where the `noutput' member is 0.
(gdb) p *resources
$5 = {
timestamp = 1653376136,
configTimestamp = 1653376136,
ncrtc = 0,
crtcs = 0x101457270,
noutput = 0,
outputs = 0x101457270,
nmode = 0,
modes = 0x101457270
}
GDK also uses XRRGetScreenResourcesCurrent. So, in the GDK code, what
actually distinguished XRandR in XQuartz from the other
implementationswas not the comparison of the output name with
"default", but the positiveness of the `noutput' member.
static gboolean
init_randr13 (GdkScreen *screen)
{
:
monitors = g_array_sized_new (FALSE, TRUE, sizeof (GdkX11Monitor),
resources->noutput);
:
x11_screen->n_monitors = monitors->len;
:
return x11_screen->n_monitors > 0;
}
YAMAMOTO Mitsuharu
address@hidden
- Re: x-display-pixel-width/height inconsistency, Jan Djärv, 2013/05/01
- Re: x-display-pixel-width/height inconsistency,
YAMAMOTO Mitsuharu <=
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/05
- Re: x-display-pixel-width/height inconsistency, Stefan Monnier, 2013/05/05
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/06
- Re: x-display-pixel-width/height inconsistency, Stefan Monnier, 2013/05/06
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/08
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/08
- Re: x-display-pixel-width/height inconsistency, Eli Zaretskii, 2013/05/08
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/08
- Re: x-display-pixel-width/height inconsistency, Glenn Morris, 2013/05/08
- Re: x-display-pixel-width/height inconsistency, YAMAMOTO Mitsuharu, 2013/05/08