Re: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above

   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. 

Re: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above

   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

Request for uniform and contiguous resolution-independence in AWT

Re: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above

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

Re: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above

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

Re: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above

   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
> 

delivery of mouse events

Hi -

Several years ago, while working with a tablet PC, I developed a patch
to AWT that delivered all mouse events to the application.  This was
for pen applications that wanted to track exactly how the user had
moved the pen, as opposed to the default behavior, which was to
discard extraneous mouse motion events.

I only did this for X Windows, and it wasn't done as an option - I
"selected" this feature according to which version of rt.jar I used.

Anyway, now that this is open source, is this a feature we'd like to
see added to AWT?  (I'm assuming it hasn't been done already)

If so, it should probably be a runtime option.  Any suggestions for
how to turn it on and off?

 					-bwb

 					Brent Baccala
 					cosine@...

Re: delivery of mouse events

Hi Brent,

could you please provide more accurate description of the feature you 
propose.

Thanks, Oleg.

Brent Baccala wrote:
> Hi -
> 
> Several years ago, while working with a tablet PC, I developed a patch
> to AWT that delivered all mouse events to the application.  This was
> for pen applications that wanted to track exactly how the user had
> moved the pen, as opposed to the default behavior, which was to
> discard extraneous mouse motion events.
> 
> I only did this for X Windows, and it wasn't done as an option - I
> "selected" this feature according to which version of rt.jar I used.
> 
> Anyway, now that this is open source, is this a feature we'd like to
> see added to AWT?  (I'm assuming it hasn't been done already)
> 
> If so, it should probably be a runtime option.  Any suggestions for
> how to turn it on and off?
> 
> 
> 
>                     -bwb
> 
>                     Brent Baccala
>                     cosine@...

Re: delivery of mouse events

On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:

> Hi Brent,
>
> could you please provide more accurate description of the feature you 
> propose.
>
> Thanks, Oleg.

See http://www.freesoft.org/software/tablet-java

This page includes a link to the patch file, but like I said, I don't
think it's suitable as is, because it should be a selectable option.

 					-bwb

 					Brent Baccala
 					cosine@...

Re: delivery of mouse events

Brent Baccala пишет:
> On Tue, 22 Jan 2008, Oleg Sukhodolsky wrote:
> 
>> Hi Brent,
>>
>> could you please provide more accurate description of the feature you 
>> propose.
>>
>> Thanks, Oleg.
> 
> See http://www.freesoft.org/software/tablet-java
> 
> This page includes a link to the patch file, but like I said, I don't
> think it's suitable as is, because it should be a selectable option.

So, if I've got the changes wright, you would like to have an option to 
disable coalescing of mouse events.  Am I right?
IMHO it is a good idea and I would be happy to have this feature in our 
code.

Oleg.