From Dmitri.Trembovetski at Sun.COM Fri Jan 4 16:16:27 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 04 Jan 2008 16:16:27 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive
Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <4769B004.10308@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM>
Message-ID: <477ECC5B.6050703@Sun.COM>
Hi Dan,
did you receive a confirmation about the SCA?
Thanks,
Dmitri
Dmitri Trembovetski wrote:
>
> Hi Dan,
>
> I know that you sent your SCA (repeatedly =) so
> I looked at the fix.
>
> It looks good.
>
> Please see my comments below.
>
> Dan Munckton wrote:
>> APPROACH
>>
>> The fix is really simple it just checks to make sure RANDR's version is
>> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
>> to load the libXrandr funcs.
>
> Sounds good.
>
>> For the moment I've completely ignored 6599351, and not touched any of
>> the Xinerama loading code at all.
>
> OK, I think it's a good idea to separate the two fixes.
>
>> BTW I note that with 6599351 the user has an old style X dual-head
>> config without using Xinerama - I found a note on the Debian Xrandr1.2
>> Howto wiki page [1] explaining that this configuration should crash
>> Xserver 1.3. Does it behave differently in Solaris X?
>
> You mean, if randr is present?
> It could be that it didn't have randr extension.
> It looks from the comments in the bug report that 1.3 works
> fine with dual screens w/o xinerama in general.
>
>> TESTING
>>
>> The equipment I have here will allow me to test single monitor setups
>> with X servers 1.2 and 1.3. Java now behaves as expected in the
>> following cases:
>>
>> 1) Xserver 1.2 + 1 monitor + Xrandr
>> Expect: isFullScreenSupported: true
>> Result: PASS
>>
>> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
>> load but Xrandr and DRI won't load either)
>> Expect: isFullScreenSupported: false
>> Result: PASS
>>
>> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
>> Expect: isFullScreenSupported: true
>> Result: PASS
>>
>> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
>> load but Xrandr and DRI won't load either)
>> Expect: isFullScreenSupported: false
>> Result: PASS
>
> I assume this is all on linux, right?
>
>> TESTING TODO
>>
>> I have an external LCD monitor at work which I can hook up to my laptop
>> next week. This should allow me to test out Xrandr 1.2 multi-monitor
>> setups. I'll post results as soon as complete.
>>
>> However I don't think I can test out Xinerama dual head configs. I tried
>> to set this up once before but failed - I'm still not 100% certain if
>> Xinerama is actually compiled into my X server I will need to check this
>> out properly.
>> If anyone here has a multi monitor setup already and would be prepared
>> to help me test the following scenarios I'd be very grateful.
>>
>> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
>> Expect: isFullScreenSupported: false
>>
>> 6) Xserver 1.3 + 2 monitors + Xinerama
>> Expect: isFullScreenSupported: false
>
> Ugh. That might be a problem - we don't have too many
> multiscreen solaris or linux systems that we could install
> new X server on. But we'll see what we can do.
>
> We can at least test on the configuration we have.
> I have a Solaris 10 machine with dual (non-xinerama)
> screen - the fs mode isn't supported on it.
>
>> I am also still to run the jtreg tests against this. I will come back
>> with results.
>
> I can't think of a good automated regression test for this fix.
> You can I suppose write a jtreg regression test as script
> (it is allowed), run xdpyinfo and find out that randr of the
> correct version is installed and then test if fullscreen
> is supported but it may not necessarily be a fully correct test -
> fullscreen may not be enabled for other reasons.
>
>> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
>> future?
>
> This particular fix is 2D only, so we can continue on 2d-dev.
> The other one - we'll see. I suppose it's not that much of a problem
> if you cc both lists.
>
> Thanks,
> Dmitri
>
>
>>
>> Cheers
>>
>> Dan
>>
>>
>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
>> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>>
From Dmitri.Trembovetski at Sun.COM Fri Jan 4 16:26:06 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 04 Jan 2008 16:26:06 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive
Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <477ECC5B.6050703@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM>
<477ECC5B.6050703@Sun.COM>
Message-ID: <477ECE9E.7020106@Sun.COM>
OK, Phil actually bothered to check, and now we see
your name in the list of SCA signatories! Woo-hoo!
Thanks,
Dmitri
Dmitri Trembovetski wrote:
>
> Hi Dan,
>
> did you receive a confirmation about the SCA?
>
> Thanks,
> Dmitri
>
>
> Dmitri Trembovetski wrote:
>>
>> Hi Dan,
>>
>> I know that you sent your SCA (repeatedly =) so
>> I looked at the fix.
>>
>> It looks good.
>>
>> Please see my comments below.
>>
>> Dan Munckton wrote:
>>> APPROACH
>>>
>>> The fix is really simple it just checks to make sure RANDR's version is
>>> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
>>> to load the libXrandr funcs.
>>
>> Sounds good.
>>
>>> For the moment I've completely ignored 6599351, and not touched any of
>>> the Xinerama loading code at all.
>>
>> OK, I think it's a good idea to separate the two fixes.
>>
>>> BTW I note that with 6599351 the user has an old style X dual-head
>>> config without using Xinerama - I found a note on the Debian Xrandr1.2
>>> Howto wiki page [1] explaining that this configuration should crash
>>> Xserver 1.3. Does it behave differently in Solaris X?
>>
>> You mean, if randr is present?
>> It could be that it didn't have randr extension.
>> It looks from the comments in the bug report that 1.3 works
>> fine with dual screens w/o xinerama in general.
>>
>>> TESTING
>>>
>>> The equipment I have here will allow me to test single monitor setups
>>> with X servers 1.2 and 1.3. Java now behaves as expected in the
>>> following cases:
>>>
>>> 1) Xserver 1.2 + 1 monitor + Xrandr
>>> Expect: isFullScreenSupported: true
>>> Result: PASS
>>>
>>> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
>>> load but Xrandr and DRI won't load either)
>>> Expect: isFullScreenSupported: false
>>> Result: PASS
>>>
>>> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
>>> Expect: isFullScreenSupported: true
>>> Result: PASS
>>>
>>> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
>>> load but Xrandr and DRI won't load either)
>>> Expect: isFullScreenSupported: false
>>> Result: PASS
>>
>> I assume this is all on linux, right?
>>
>>> TESTING TODO
>>>
>>> I have an external LCD monitor at work which I can hook up to my laptop
>>> next week. This should allow me to test out Xrandr 1.2 multi-monitor
>>> setups. I'll post results as soon as complete.
>>>
>>> However I don't think I can test out Xinerama dual head configs. I tried
>>> to set this up once before but failed - I'm still not 100% certain if
>>> Xinerama is actually compiled into my X server I will need to check this
>>> out properly.
>>> If anyone here has a multi monitor setup already and would be prepared
>>> to help me test the following scenarios I'd be very grateful.
>>>
>>> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
>>> Expect: isFullScreenSupported: false
>>>
>>> 6) Xserver 1.3 + 2 monitors + Xinerama
>>> Expect: isFullScreenSupported: false
>>
>> Ugh. That might be a problem - we don't have too many
>> multiscreen solaris or linux systems that we could install
>> new X server on. But we'll see what we can do.
>>
>> We can at least test on the configuration we have.
>> I have a Solaris 10 machine with dual (non-xinerama)
>> screen - the fs mode isn't supported on it.
>>
>>> I am also still to run the jtreg tests against this. I will come back
>>> with results.
>>
>> I can't think of a good automated regression test for this fix.
>> You can I suppose write a jtreg regression test as script
>> (it is allowed), run xdpyinfo and find out that randr of the
>> correct version is installed and then test if fullscreen
>> is supported but it may not necessarily be a fully correct test -
>> fullscreen may not be enabled for other reasons.
>>
>>> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
>>> future?
>>
>> This particular fix is 2D only, so we can continue on 2d-dev.
>> The other one - we'll see. I suppose it's not that much of a problem
>> if you cc both lists.
>>
>> Thanks,
>> Dmitri
>>
>>
>>>
>>> Cheers
>>>
>>> Dan
>>>
>>>
>>> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
>>> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>>>
From Ben.LOUD at baesystems.com Mon Jan 14 05:39:45 2008
From: Ben.LOUD at baesystems.com (LOUD, Ben)
Date: Tue, 15 Jan 2008 00:09:45 +1030
Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double
Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com>
I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included.
Thats all. Thanks!
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited. If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility. It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080115/0a1f6f97/attachment.html
From Jim.A.Graham at Sun.COM Mon Jan 14 12:07:50 2008
From: Jim.A.Graham at Sun.COM (Jim Graham)
Date: Mon, 14 Jan 2008 12:07:50 -0800
Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double
In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com>
References: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com>
Message-ID: <0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com>
Hi Ben,
Since it was only used for doing component layouts (in integer space),
it wasn't really needed anywhere, though I suppose that this begs the
question as to why Dimension2D was created in the first place.
(scratches head, doesn't remember).
Do you have a use case for it now?
...jim
LOUD, Ben wrote:
> I was just wondering, is there any reason why there are no Float and Double subclasses of Dimension2D? I'm suprised such a simple thing was never included.
>
> Thats all. Thanks!
>
>
> "Warning:
> The information contained in this email and any attached files is
> confidential to BAE Systems Australia. If you are not the intended
> recipient, any use, disclosure or copying of this email or any
> attachments is expressly prohibited. If you have received this email
> in error, please notify us immediately. VIRUS: Every care has been
> taken to ensure this email and its attachments are virus free,
> however, any loss or damage incurred in using this email is not the
> sender's responsibility. It is your responsibility to ensure virus
> checks are completed before installing any data sent in this email to
> your computer."
>
>
From Ben.LOUD at baesystems.com Mon Jan 14 16:27:46 2008
From: Ben.LOUD at baesystems.com (LOUD, Ben)
Date: Tue, 15 Jan 2008 10:57:46 +1030
Subject: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double
In-Reply-To: <0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com>
References: <755F5FA20B29364FBA287DB1BEBCE80A012CAF74@SBEMAIL1.au.baesystems.com>
<0JUN00BM7H6O1OE0@fe-sfbay-09.sun.com>
Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A037C3216@SBEMAIL1.au.baesystems.com>
Yeah, it would come in handy just for general purpose use. I was
planning an API where I simply needed to return a width and height in
double precision, and obviously would prefer to use standard classes. In
this case, it was for layout of graphic elements, but in user space, and
I needed to stay resolution independent (for printing). Essentially I
had the equivelant of AWT's getPreferredSize().
Not a showstopper, but I thought they might be worthy of inclusion, even
for the sake of completeness.
-----Original Message-----
From: Jim.A.Graham at sun.com [mailto:Jim.A.Graham at sun.com]
Sent: Tuesday, 15 January 2008 6:38 AM
To: LOUD, Ben
Cc: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] 4189647 - Dimension2D.Float/.Double
Hi Ben,
Since it was only used for doing component layouts (in integer space),
it wasn't really needed anywhere, though I suppose that this begs the
question as to why Dimension2D was created in the first place.
(scratches head, doesn't remember).
Do you have a use case for it now?
...jim
LOUD, Ben wrote:
> I was just wondering, is there any reason why there are no Float and
Double subclasses of Dimension2D? I'm suprised such a simple thing was
never included.
>
> Thats all. Thanks!
>
>
> "Warning:
> The information contained in this email and any attached files is
> confidential to BAE Systems Australia. If you are not the intended
> recipient, any use, disclosure or copying of this email or any
> attachments is expressly prohibited. If you have received this email
> in error, please notify us immediately. VIRUS: Every care has been
> taken to ensure this email and its attachments are virus free,
> however, any loss or damage incurred in using this email is not the
> sender's responsibility. It is your responsibility to ensure virus
> checks are completed before installing any data sent in this email to
> your computer."
>
>
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited. If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility. It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."
From lists at munckfish.net Wed Jan 16 07:37:39 2008
From: lists at munckfish.net (Dan Munckton)
Date: Wed, 16 Jan 2008 15:37:39 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
Exclusive Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1197369278.7494.8.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
<1197369278.7494.8.camel@dylan>
Message-ID: <1200497859.7514.14.camel@dylan>
Hi all
Happy new year.
Although I've been silent for a bit, I'm still working on this. I've
tested more widely now and have managed to configure multi-monitor
setups on both Xorg server's 1.2 and 1.3. I'm also now on the SCA
contributors list.
UPDATED PATCH
Please see the attached updated patch.
I needed to add code to prevent FSEM (Fullscreen Exclusive Mode) on Xorg
1.3 with 2 or more monitors. Although I suspect this is technically
possible now (as it is in Windows) running a full-screen app in a
multi-monitor setup currently disables all Graphics devices except the
default and requires an X restart to bring them back. So I guess it'll
need more work to support that.
Should I raise an RFE? Is this something worth doing?
FEEDBACK SO FAR
Guys, am I on the right lines?
Yuri, you were going to work on 6599351, does what I've done fit in or
were you planning more radical changes?
ADVICE ON JTREG APPROACH
Also I need some advice on how to approach a jtreg test for this. My
current plan is to use a shell script to query command line tools like
xdpyinfo and xrandr and then run a Java tool to check whether FSEM is or
isn't supported as expected. But I've no idea (yet) how portable this
would be across platforms and across versions of X.
I notice there aren't a great deal FSEM related tests in the source
other than one in jdk/test/java/awt/Fullscreen (which incidentally
appears to be missing a source file 'DisplayModeChanger.java').
I can see the benefit in providing a regression test for this but I'm
concerned that it's very dependent on the environment the tests are
being run on as to whether it'll get spotted at all.
Do you guys think it's a good idea to make a test for this or is it more
likely to be a pest to maintain?
Thanks
Dan Munckton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_v2.diff
Type: text/x-patch
Size: 3709 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080116/ebe7d3f6/6636469_v2.diff
From lists at munckfish.net Thu Jan 17 10:10:10 2008
From: lists at munckfish.net (Dan Munckton)
Date: Thu, 17 Jan 2008 18:10:10 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
Exclusive Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1200497859.7514.14.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
Message-ID: <1200593410.6546.2.camel@dylan>
Hi
Please disregard all of my previous patches. I've just fixed a logic
error I made when checking the RANDR version. Now fixed, patch v3
attached.
Thanks
Dan Munckton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_v3.diff
Type: text/x-patch
Size: 3738 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080117/503c97cb/6636469_v3.diff
From Dmitri.Trembovetski at Sun.COM Thu Jan 17 10:40:00 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 17 Jan 2008 10:40:00 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java
Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <1200593410.6546.2.camel@dylan>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
<1200593410.6546.2.camel@dylan>
Message-ID: <478FA100.7070401@Sun.COM>
Hi Dan,
the patch looks fine.
The only thing is that we typically try to avoid
the use of goto if possible (like in this case since you
don't win much by using it), so I'd suggest to
just use
+ dlclose(pLibRandR);
+ return JNI_FALSE;
instead of
+ goto return_false;
Disabling fullscreen for multiscreen systems is ok with
me.
I agree that it'll be hard to create a robust automated
test for this bug (and there's plenty of manual tests
already, adding a new one won't be of much benefit),
so I suggest we skip on regression test for this one.
Regarding testing configurations: I have requested
a sparc system with Nevada (so that it has the new X server),
and also an x86/64 machine for linux/solaris. Once
we have those set up we can proceed with the integration.
Thanks,
Dmitri
Dan Munckton wrote:
> Hi
>
> Please disregard all of my previous patches. I've just fixed a logic
> error I made when checking the RANDR version. Now fixed, patch v3
> attached.
>
> Thanks
>
> Dan Munckton
>
From lists at munckfish.net Fri Jan 18 05:26:00 2008
From: lists at munckfish.net (Dan Munckton)
Date: Fri, 18 Jan 2008 13:26:00 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
Exclusive Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <4769B004.10308@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <4769B004.10308@Sun.COM>
Message-ID: <1200662760.6148.43.camel@dylan>
Hi Dmitri
Apologies. I've only just seen this mail - I setup a spam filter before
Xmas but it was too keen. I've just rescued this mail (and 3 others you
sent late 07) from my Junk folder. Grrr. Spam filter switched to OFF
now :)
> I know that you sent your SCA (repeatedly =) so
> I looked at the fix.
>
> It looks good.
Excellent thanks. What a relief!
> > BTW I note that with 6599351 the user has an old style X dual-head
> > config without using Xinerama - I found a note on the Debian Xrandr1.2
> > Howto wiki page [1] explaining that this configuration should crash
> > Xserver 1.3. Does it behave differently in Solaris X?
>
> You mean, if randr is present?
Yes.
> It could be that it didn't have randr extension.
> It looks from the comments in the bug report that 1.3 works
> fine with dual screens w/o xinerama in general.
Ok maybe I misinterpreted the comments. I thought that although the guy
said he wasn't explicitly using Xinerama (ie not positively enabled in
xorg.conf) that it was in fact still enabled because of the new RANDR
1.2 backend. Anyway I'm still not sure I can recreate that issue with
the gear I have here.
>
> > TESTING
> >
>
> I assume this is all on linux, right?
Yes. I'm currently running Ubuntu 7.04 (Feisty) which has Xorg server
1.2. To test with Xorg server 1.3 I've been using the bootable CD-ROM of
Ubuntu 7.10 (Gutsy).
I'm using a laptop with ATI RADEON X700. The laptop monitor is a
1440x900 LCD panel. It has an extra VGA out which I'm connecting to a
19" LCD external monitor.
>
> > TESTING TODO
> > If anyone here has a multi monitor setup already and would be prepared
> > to help me test the following scenarios I'd be very grateful.
> >
> > 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
> > Expect: isFullScreenSupported: false
> >
> > 6) Xserver 1.3 + 2 monitors + Xinerama
> > Expect: isFullScreenSupported: false
>
> Ugh. That might be a problem - we don't have too many
> multiscreen solaris or linux systems that we could install
> new X server on. But we'll see what we can do.
>
> We can at least test on the configuration we have.
> I have a Solaris 10 machine with dual (non-xinerama)
> screen - the fs mode isn't supported on it.
>
In fact I have now been able to test cases 5 & 6 above.
Is your Solaris machine using what people refer to as the "old style
dual-head" configuration enabled with Option "DualHead" "true" in
xorg.conf? If so this is something I haven't been able to setup here.
But it's interesting you can't use FSEM as I would have presumed this
possible as long as Xinerama isn't actually in use.
Cheers
Dan
From lists at munckfish.net Fri Jan 18 06:10:23 2008
From: lists at munckfish.net (Dan Munckton)
Date: Fri, 18 Jan 2008 14:10:23 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
Exclusive Mode not working with Xorg server 1.3.0 and above
In-Reply-To: <478FA100.7070401@Sun.COM>
References: <1197121416.14405.50.camel@dylan> <475AF914.1090309@sun.com>
<1197369278.7494.8.camel@dylan> <1200497859.7514.14.camel@dylan>
<1200593410.6546.2.camel@dylan> <478FA100.7070401@Sun.COM>
Message-ID: <1200665423.6148.77.camel@dylan>
Hi
New patch attached with updates as requested.
Note that I have also moved the logic which ensures single screen only
configs within the "if (usingXinerama)" block below the RANDR version
check. I just feel this is tidier it means that the code path for users
of Xorg server 1.2 and below is exactly as before, and the patch then
only adds support for users of Xorg 1.3 and above and no more.
>
> I agree that it'll be hard to create a robust automated
> test for this bug (and there's plenty of manual tests
> already, adding a new one won't be of much benefit),
> so I suggest we skip on regression test for this one.
Ok fine.
One important thing I'd like to bring to your attention is this: so far
I've been testing FSEM mode using my employer's own fullscreen product
[0] and it's been working fine. Today I decided to check using the
DisplayModeTest example from the Java Fullscreen Exclusive Mode Tutorial
[1]. With this app on Xorg 1.3/RANDR 1.2, the mouse cursor is lost after
changing display mode. Sometimes it pops back after a short time, other
times I have to Alt+Tab out and back in to get it back.
So far I've tried explicitly resetting the cursor
(this.setCursor(Cursor.getDefaultCursor()) and adding an extra sync
(Toolkit.getDefaultToolkit().sync()) when the mode changes but neither
of these helped any.
I'll see if I can find out more, but would welcome any suggestions as to
why this may be.
Is there a schedule available on the planned dates of Java 6 updates or
OpenJDK promotions/builds? I'm sure someone else asked this question and
was directed to the mail archives but I couldn't find a mail with the
details.
Cheers
Dan
[0] http://www.inquizitor.com/
[1]
http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/DisplayModeTest.java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_v4.diff
Type: text/x-patch
Size: 3344 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080118/f035bc09/6636469_v4.diff
From msp at altlinux.ru Wed Jan 23 06:35:47 2008
From: msp at altlinux.ru (Michael Pozhidaev)
Date: Wed, 23 Jan 2008 20:35:47 +0600
Subject: [OpenJDK 2D-Dev] PostScript generation
Message-ID:
Hello, everybody!
It is my first post to this list. Sorry, if I have chosen the list incorrectly.
I don't want to be disturbing. Please, point me to the another one, if there is the better place to discuss this problem.
The problem, I can not solve, is in postscript generator in Java.
I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution - AltLinux.
On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000 connected and configured.
My Java prints, generated with jasperreports, are placed incorrectly on the page,
moved up on 2-3cm and exceed the page border.
When I ask Java to save ps output to the file, this file can be
viewed with gs or evince. Direct call of gs with command line produces correct image,
but in evince there is the same problem as in printing.
All other applications on my machine make their prints perfectly without
any problems. My friend tried to make prints in the same system, but
with another HP laser printer, and he got a completely wrong page, just with two letters "IB" on it.
I think, is CUPS providing to Java any information about the installed printer (anything like PPPD file)?
Maybe this information is wrong for my printer or Java is not able to process it correctly?
I can sent to anybody the ps files I have received with Java and which
can not be printed correctly.
Please, help me to solve this problem.! Thanks! :)
--
With best wishes. Michael Pozhidaev.
Tomsk State University.
Computer science department.
From Jennifer.Godinez at Sun.COM Wed Jan 23 10:43:32 2008
From: Jennifer.Godinez at Sun.COM (Jennifer Godinez)
Date: Wed, 23 Jan 2008 10:43:32 -0800
Subject: [OpenJDK 2D-Dev] PostScript generation
In-Reply-To:
References:
Message-ID: <47978AD4.8060804@Sun.COM>
Hi Michael,
You mentioned you are using JasperReports. Do you use jasperreports
API? Can you send a code snippet?
jennifer
Michael Pozhidaev wrote:
> Hello, everybody!
> It is my first post to this list. Sorry, if I have chosen the list incorrectly.
> I don't want to be disturbing. Please, point me to the another one, if there is the better place to discuss this problem.
> The problem, I can not solve, is in postscript generator in Java.
> I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution - AltLinux.
> On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000 connected and configured.
> My Java prints, generated with jasperreports, are placed incorrectly on the page,
> moved up on 2-3cm and exceed the page border.
> When I ask Java to save ps output to the file, this file can be
> viewed with gs or evince. Direct call of gs with command line produces correct image,
> but in evince there is the same problem as in printing.
> All other applications on my machine make their prints perfectly without
> any problems. My friend tried to make prints in the same system, but
> with another HP laser printer, and he got a completely wrong page, just with two letters "IB" on it.
> I think, is CUPS providing to Java any information about the installed printer (anything like PPPD file)?
> Maybe this information is wrong for my printer or Java is not able to process it correctly?
> I can sent to anybody the ps files I have received with Java and which
> can not be printed correctly.
> Please, help me to solve this problem.! Thanks! :)
From Phil.Race at Sun.COM Wed Jan 23 10:47:10 2008
From: Phil.Race at Sun.COM (Phil Race)
Date: Wed, 23 Jan 2008 10:47:10 -0800
Subject: [OpenJDK 2D-Dev] PostScript generation
In-Reply-To: <47978AD4.8060804@Sun.COM>
References: <47978AD4.8060804@Sun.COM>
Message-ID: <47978BAE.8040809@sun.com>
This is not the right alias for usage questions.
Please re-direct to either :
JAVA2D-INTEREST at JAVA.SUN.COM to which you can subscribe
to that list using listserv at JAVA.SUN.COM,
Or you can post in the Java2D forum at
http://forums.java.net/jive/forum.jspa?forumID=69&start=0
-phil.
Jennifer Godinez wrote:
> Hi Michael,
>
> You mentioned you are using JasperReports. Do you use jasperreports
> API? Can you send a code snippet?
>
> jennifer
>
> Michael Pozhidaev wrote:
>> Hello, everybody!
>> It is my first post to this list. Sorry, if I have chosen the list
>> incorrectly.
>> I don't want to be disturbing. Please, point me to the another one, if
>> there is the better place to discuss this problem.
>> The problem, I can not solve, is in postscript generator in Java.
>> I am using java (both 1.4.2 and 1.6) in Russian GNU/Linux distribution
>> - AltLinux.
>> On my machine CUPS 1.2.10 is installed and I have HP LaserJet 1000
>> connected and configured.
>> My Java prints, generated with jasperreports, are placed incorrectly
>> on the page, moved up on 2-3cm and exceed the page border.
>> When I ask Java to save ps output to the file, this file can be viewed
>> with gs or evince. Direct call of gs with command line produces
>> correct image,
>> but in evince there is the same problem as in printing.
>> All other applications on my machine make their prints perfectly
>> without any problems. My friend tried to make prints in the same
>> system, but with another HP laser printer, and he got a completely
>> wrong page, just with two letters "IB" on it.
>> I think, is CUPS providing to Java any information about the installed
>> printer (anything like PPPD file)?
>> Maybe this information is wrong for my printer or Java is not able to
>> process it correctly?
>> I can sent to anybody the ps files I have received with Java and which
>> can not be printed correctly.
>> Please, help me to solve this problem.! Thanks! :)