From sacadmin Wed Dec 13 19:19:30 2006 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBE3JUJY029177; Wed, 13 Dec 2006 19:19:30 -0800 (PST) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id kBE3JUw5029172; Wed, 13 Dec 2006 19:19:30 -0800 (PST) Date: Wed, 13 Dec 2006 19:19:30 -0800 (PST) From: Alan Coopersmith Message-Id: <200612140319.kBE3JUw5029172@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: Deron.Johnson@sun.com, xserver-group@sun.com Subject: XFixes 4.0 [PSARC/2006/702 Timeout: 12/13/2006] Status: RO Content-Length: 6337 Subject: PSARC FastTrack [12/13/2006]: XFixes 4.0 I am sponsoring this case for myself and marking it closed approved automatic as it is a simple update to the latest protocol/API versions from X.Org with no compatibility issues. If anyone sees any reason this case needs further discussion/review, please let me know. The binding for this case is a Patch/Micro Release. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase %I% %G% SMI 1. Introduction 1.1. Project/Component Working Name: XFixes 4.0 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 13 December, 2006 4. Technical Description This project updates the XFixes extension protocol & API in Solaris from Version 2.0 (reviewed in PSARC 2004/318, published by X.Org in X11R6.8) to Version 4.0 (published by X.Org in X11R7.1). These changes add new protocol requests and functions but do not change existing protocol/functions, so are fully backwards compatible. XFixes Version 3 added one request to the protocol: +10. Region Expansion + +This update provides another operation on the region objects defined in +Section 8 of this document. + +10.1 Requests + +ExpandRegion + source: REGION + destination: REGION + left, right, top, bottom: CARD16 + + Creates destination region containing the area specified by each + rectangle in the source region plus the area including the specified + number of pixels to the left, right, top and bottom of each + rectangle in the source region. XFixes Version 4 adds two more requests to the protocol: +11. Cursor Visibility + +Composite managers may want to render the cursor themselves instead of +relying on the X server sprite drawing, this provides a way for them to +do so without getting a double cursor image. + +11.1 Requests + +HideCursor + + window: WINDOW + + A client sends this request to indicate that it wants the + cursor image to be hidden (i.e. to not be displayed) when + the sprite is inside the specified window, or one of its + subwindows. If the sprite is inside a window for which one + or more active clients have requested cursor hiding then the + cursor image will not be displayed. + + Note that even though cursor hiding causes the cursor image + to be invisible, CursorNotify events will still be sent + normally, as if the cursor image were visible. + + If, during a grab, one or more active clients have requested + cursor hiding for grab window, or one of its ancestors, the + cursor image of the grab cursor will not be displayed during + the lifetime of that grab. + + When a client with outstanding cursor hiding requests + terminates its connection these requests will be deleted. + +ShowCursor + + window: WINDOW + + A client sends this request to indicate that it wants the + cursor image to be displayed when the sprite is inside the + specified window, or one of its subwindows. If the sprite + is inside a window for which no active clients have requested + cursor hiding then the cursor image for that window will be + displayed. In other words, if a client calls HideCursor for + a specified window, or window subtree, this request reverses + the effects of the HideCursor request. + + If the client has made no outstanding HideCursor requests + a BadMatch error is generated. Each of these requests had a corresponding client API function added to libXfixes: void XFixesExpandRegion (Display *dpy, XserverRegion dst, XserverRegion src, unsigned left, unsigned right, unsigned top, unsigned bottom); void XFixesHideCursor (Display *dpy, Window win); void XFixesShowCursor (Display *dpy, Window win); ------------------------------------------------------------------------ Additionally, this case raises the stability of the interfaces from External/Volatile to Uncommitted. The prior review (PSARC 2004/318) stated: XFixes is planned to be included in an XORG Foundation xserver release sometime during the next three months (the planned release version is X11R6.7.1). It is also expected that the XORG Foundation will issue a formal and official standard for the XFixes extension. Until the standardization process is completed the XFixes extension is classified as External. After XORG makes XFixes a standard the interface classification will be changed to Standard, and at that time a fast-track will be filed to update the XFixes interface classification. X.Org has included XFixes since X11R6.8 and continues to publish it as a supported interface, but has not yet formally standardized it. We believe it has been adopted widely enough and the community constraints covering it are strong enough to allow making it Uncommitted stability, while we continue to wait for formal standardization. Imported interfaces: Interface Classification Comments --------------------- --------------- --------------- libXFixes.so.1 External PSARC 2004/318 Xfixes.h External PSARC 2004/318 Xfixesint.h External PSARC 2004/318 xfixesproto.h External PSARC 2004/318 xfixeswire.h External PSARC 2004/318 Exported interfaces: Interface Classification Comments --------------------- --------------- --------------- libXFixes.so.1 Uncommitted PSARC 2004/318 & this case Xfixes.h Uncommitted PSARC 2004/318 & this case Xfixesint.h Uncommitted PSARC 2004/318 & this case xfixesproto.h Uncommitted PSARC 2004/318 & this case xfixeswire.h Uncommitted PSARC 2004/318 & this case References: [1] protocol-spec.txt - XFixes 4.0 Protocol Spec (portions quoted above) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: FastTrack From sacadmin Thu Dec 14 07:31:08 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBEFV7FD013681; Thu, 14 Dec 2006 07:31:07 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kBEFTnrm003274; Thu, 14 Dec 2006 15:29:49 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kBEFTmtb003273; Thu, 14 Dec 2006 10:29:48 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: XFixes 4.0 [PSARC/2006/702 Timeout: 12/13/2006] From: Bill Sommerfeld To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com, Deron.Johnson@sun.com, xserver-group@sun.com In-Reply-To: <200612140319.kBE3JUw5029172@sac.sfbay.sun.com> References: <200612140319.kBE3JUw5029172@sac.sfbay.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 14 Dec 2006 10:29:47 -0500 Message-Id: <1166110188.2691.35.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Status: RO Content-Length: 1344 On Wed, 2006-12-13 at 19:19 -0800, Alan Coopersmith wrote: > XFixes Version 3 added one request to the protocol: > > +10. Region Expansion > + > +This update provides another operation on the region objects defined in > +Section 8 of this document. > + > +10.1 Requests > + > +ExpandRegion > + source: REGION > + destination: REGION > + left, right, top, bottom: CARD16 > + > + Creates destination region containing the area specified by each > + rectangle in the source region plus the area including the specified > + number of pixels to the left, right, top and bottom of each > + rectangle in the source region. I'd like to see an answer to this question recorded (and fed back to the X folks to clarify their spec if it's not nailed down elsewhere in their specs) but I don't care what the answer is: When you expand a region on two adjacent sides, does the expanded region include the "corners" as well? (if your mail reader doesn't use a fixed-width font to render this next bit, you'll be confused): In other words, if I expand region "x" by 2 pixels on all sides, do I get: ...****... ...****... .**xxxx**. ...****... ...****... or: .********. .********. .**xxxx**. .********. .********. ? - Bill From sacadmin Thu Dec 14 10:02:14 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBEI2E7j017182; Thu, 14 Dec 2006 10:02:14 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-26-173.SFBay.Sun.COM [129.150.26.173]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBEI2BC4013347; Thu, 14 Dec 2006 10:02:13 -0800 (PST) Message-ID: <45819160.2090904@sun.com> Date: Thu, 14 Dec 2006 10:01:04 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Bill Sommerfeld CC: Alan Coopersmith , PSARC@sac.sfbay.sun.com, Deron.Johnson@sun.com, xserver-group@sun.com Subject: Re: XFixes 4.0 [PSARC/2006/702 Timeout: 12/13/2006] References: <200612140319.kBE3JUw5029172@sac.sfbay.sun.com> <1166110188.2691.35.camel@localhost> In-Reply-To: <1166110188.2691.35.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1724 Bill Sommerfeld wrote: > On Wed, 2006-12-13 at 19:19 -0800, Alan Coopersmith wrote: > >> XFixes Version 3 added one request to the protocol: >> >> +10. Region Expansion >> + >> +This update provides another operation on the region objects defined in >> +Section 8 of this document. >> + >> +10.1 Requests >> + >> +ExpandRegion >> + source: REGION >> + destination: REGION >> + left, right, top, bottom: CARD16 >> + >> + Creates destination region containing the area specified by each >> + rectangle in the source region plus the area including the specified >> + number of pixels to the left, right, top and bottom of each >> + rectangle in the source region. > > I'd like to see an answer to this question recorded (and fed back to the > X folks to clarify their spec if it's not nailed down elsewhere in their > specs) but I don't care what the answer is: > > When you expand a region on two adjacent sides, does the expanded region > include the "corners" as well? Yes. In psuedo-code the operation is: initialize destregion to empty foreach srcrect in srcregion destrect.x1 = srcrect.x1 - left; destrect.x2 = srcrect.x2 + right; destrect.y1 = srcrect.y1 - top; destrect.y2 = srcrect.y2 + bottom; destregion = union(destregion, destrect) Would this wording be clearer? + Creates destination region containing the area specified by + expanding each rectangle in the source region by the specified + number of pixels to the left, right, top and bottom. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Dec 14 10:54:54 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBEIsrtt018649; Thu, 14 Dec 2006 10:54:54 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBEIsqQ5006770; Thu, 14 Dec 2006 13:54:52 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kBEIsqmx001345; Thu, 14 Dec 2006 13:54:52 -0500 (EST) Subject: Re: XFixes 4.0 [PSARC/2006/702 Timeout: 12/13/2006] From: Bill Sommerfeld To: Alan Coopersmith Cc: Alan Coopersmith , PSARC@sac.sfbay.sun.com, Deron.Johnson@sun.com, xserver-group@sun.com In-Reply-To: <45819160.2090904@sun.com> References: <200612140319.kBE3JUw5029172@sac.sfbay.sun.com> <1166110188.2691.35.camel@localhost> <45819160.2090904@sun.com> Content-Type: text/plain Date: Thu, 14 Dec 2006 13:54:52 -0500 Message-Id: <1166122492.1317.1.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 390 On Thu, 2006-12-14 at 10:01 -0800, Alan Coopersmith wrote: > Would this wording be clearer? > > + Creates destination region containing the area specified by > + expanding each rectangle in the source region by the specified > + number of pixels to the left, right, top and bottom. Yes. (And you get bonus points because the revised version is shorter..) - Bill