help: is there any way to use integer 64 type in protocol?

[Wang, Quanxian]

Hi,

Is there any way to use type of integer 64bit in protocol?

Currently I found I could not use 64bit. Any suggestion for that?

Only below basic data types are supported in wayland.

254 union wl_argument {
255 int32_t i; /**< signed integer */
256 uint32_t u; /**< unsigned integer */
257 wl_fixed_t f; /**< fixed point */
258 const char *s; /**< string */
259 struct wl_object *o; /**< object */
260 uint32_t n; /**< new_id */
261 struct wl_array *a; /**< array */
262 int32_t h; /**< file descriptor */
263 };

Regards

Thanks

Quanxian Wang


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: help: is there any way to use integer 64 type in protocol?

[Pekka Paalanen]

On Sun, 20 Apr 2014 11:10:15 +
"Wang, Quanxian"  wrote:

> Hi,
> 
> Is there any way to use type of integer 64bit in protocol?

No. You will have to use two 32-bit arguments, or propose a patch
to add 64-bit types in a completely backwards-compatible way. I am
not sure what the latter option would entail.

The presentation extension could make use of a 64-bit type, too.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: help: is there any way to use integer 64 type in protocol?

[Jason Ekstrand]

On Sun, Apr 20, 2014 at 1:17 PM, Pekka Paalanen  wrote:

> On Sun, 20 Apr 2014 11:10:15 +
> "Wang, Quanxian"  wrote:
>
> > Hi,
> >
> > Is there any way to use type of integer 64bit in protocol?
>
> No. You will have to use two 32-bit arguments, or propose a patch
> to add 64-bit types in a completely backwards-compatible way. I am
> not sure what the latter option would entail.
>

Adding 64-bit types wouldn't be too hard.  It would involve adding a
int64_t an uint64_t types to wl_argument (I'd call them U and I personally)
and adding code throughout libwayland to parse them.  In terms of backwards
compatibility, it should be fine as long as you make it 100% clear that
your new protocol extension uses the new 64bit types and therefore requires
the newer libwayland version.

The other option is that you could do what Pekka did in the presentation
extension and split it into two 32-bit parts.  What do you want to
represent that needs a 64-bit type?

Thanks,
--Jason Ekstrand


>
> The presentation extension could make use of a 64-bit type, too.
>

>
> Thanks,
> pq
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: help: is there any way to use integer 64 type in protocol?

[Thiago Macieira]

Em dom 20 abr 2014, às 17:31:48, Jason Ekstrand escreveu:
> Adding 64-bit types wouldn't be too hard.  It would involve adding a
> int64_t an uint64_t types to wl_argument (I'd call them U and I personally)
> and adding code throughout libwayland to parse them.  In terms of backwards
> compatibility, it should be fine as long as you make it 100% clear that
> your new protocol extension uses the new 64bit types and therefore requires
> the newer libwayland version.

That changes the size and alignment of wl_argument on 32-bit platforms. No can 
do until libwayland 2.0, with a binary compatibility break.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: help: is there any way to use integer 64 type in protocol?

[Wang, Quanxian]

From: Jason Ekstrand [mailto:ja...@jlekstrand.net]
Sent: Monday, April 21, 2014 6:32 AM
To: Pekka Paalanen
Cc: Wang, Quanxian; wayland-devel@lists.freedesktop.org
Subject: Re: help: is there any way to use integer 64 type in protocol?



On Sun, Apr 20, 2014 at 1:17 PM, Pekka Paalanen 
mailto:ppaala...@gmail.com>> wrote:
On Sun, 20 Apr 2014 11:10:15 +
"Wang, Quanxian" mailto:quanxian.w...@intel.com>> 
wrote:

> Hi,
>
> Is there any way to use type of integer 64bit in protocol?
No. You will have to use two 32-bit arguments, or propose a patch
to add 64-bit types in a completely backwards-compatible way. I am
not sure what the latter option would entail.

Adding 64-bit types wouldn't be too hard.  It would involve adding a int64_t an 
uint64_t types to wl_argument (I'd call them U and I personally) and adding 
code throughout libwayland to parse them.  In terms of backwards compatibility, 
it should be fine as long as you make it 100% clear that your new protocol 
extension uses the new 64bit types and therefore requires the newer libwayland 
version.
The other option is that you could do what Pekka did in the presentation 
extension and split it into two 32-bit parts.  What do you want to represent 
that needs a 64-bit type?
[Wang, Quanxian] 32 is too short. Currently I use 32bit in Weston randr, it 
could only stand for 16 type of operations (every type use 2 bits, however 12 
of 16 have been used.). It will be fine to use 64 bit or more for future 
extension. I will try to add a patch for that. Thanks for your comment.
Thanks,
--Jason Ekstrand


The presentation extension could make use of a 64-bit type, too.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston testing (Re: New to wayland, need help pls.)

[Srivardhan M S]

Pardon me for the delayed response. I was on a vacation.

Thank you very much for the reply. As I told I am new to Wayland (indeed
new to Display server). I am going through the documentation of the Wayland
which is available in the website.

My understanding of Wayland is very little, so I won't be able to develop
the test suite myself. I will now start going through the code and logs to
understand how Wayland actually works. If any of you can guide me
initially, I would be happy to develop.

Thank-you,
Sri


On Thu, Apr 17, 2014 at 12:23 PM, Pekka Paalanen wrote:

> On Wed, 16 Apr 2014 20:41:50 +
> "Bryce W. Harrington"  wrote:
>
> > On Wed, Apr 16, 2014 at 08:51:21AM +0300, Pekka Paalanen wrote:
> > > On Tue, 15 Apr 2014 19:08:12 +
> > > "Bryce W. Harrington"  wrote:
> > >
> > > > Maybe adding more tests?  Any particular features recently added that
> > > > could benefit from tests added?
> > >
> > > Yes! That is a good one. Either adding completely new tests, or maybe
> > > working with Marek Chalupa in converting all possible FAIL_TEST cases
> to
> > > normal TEST cases, as permitted by Marek's
> > >
> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014190.html
> > >
> > > I can't list any features off-hand that would need new tests which
> would
> > > be easy to implement.
> >
> > Would there be value to just basic unit tests on some of the established
> > API's?  E.g. like take xdg-shell's API, check passing in negative or
> > zero dimentions, crazy long strings for string params, stuff like that.
> > A lot of the protocol's code is generated so it's unclear to me whether
> > this level of testing would be useful or not, but if it is, it tends to
> > be pretty newbie-friendly.
>
> Even when the wrappers are generated, argument validity checks are
> written manually, so yes, there would be value in writing those.
>
> Another easy bit is testing object destruction orders for somehow
> related objects. Like if you create a wl_viewport for wl_surface, and
> then the wl_surface is destroyed, the wl_viewport should be inert and
> using it should only be ignored in the compositor, not cause crashes or
> protocol errors. "Inert" is a specific term in the specification
> language for exactly that.
>
> The sub-surface tests do extensive destroy order testing, but I think
> it might lack testing the "ignore" part, and I'm sure there would be
> other places to add more such tests.
>
> Also, every defined protocol error in the protocol specifications should
> be excercised by a test, that should be easy, too.
>
> However, I'm not sure if xdg_shell particularly is a good target at the
> moment, as I think there might still be changes coming?
>
> > > But I guess we should at some point hook up a
> > > real renderer to the headless backend, and add infrastructure for the
> > > test framework to do screencaptures, so we could test also rendering
> > > and things like window stacking and surface/buffer transformations.
> >
> > That sounds keen, and could open up a lot of testing potential.  Shame
> > it's not already in place!  Could you elaborate on how you think this
> > could be created?  I'd like to explore this further myself.
>
> Well, there is the test protocol extension, you could add
> client-initiated screenshooting feature to it, perhaps on a designated
> sub-rectangle.
>
> Easiest for headless would probably be to start by plugging in the
> pixman renderer, and defining a hardcoded single-resolution output.
>
> Since tests also run the desktop-shell client which draws "random"
> things like takes colors from configs and paints the clock, maybe it
> could on init check if the test extension is advertised by the
> compositor. If the test extension is there, desktop-shell client would
> use only hardcoded configs, and paint a hardcoded time in the clock,
> etc. so that the rendered output should always be the same.
>
> Window initial position randomization in shell.c might be a problem.
>
> You'd also need to save the screenshots into image files, so a
> developer can check the result.
>
> > > Pixman's fuzzer test might be a good inspiration on how to actually do
> > > the tests once the infrastructure is up:
> > > http://lists.freedesktop.org/archives/pixman/2014-April/003229.html
> > > Provided we can guarantee pixel-perfect rendering, which might not
> > > always be true, so a checksum-based checking might not always work.
> >
> > I take it this is similar to the Cairo testsuite's perceptual diff
> > stuff?  (Checksumming two bitmaps pixel by pixel)
>
> I suppose, though I haven't looked at Cairo.
>
> > What we're seeing in Cairo is that sometimes pixel differences indicate
> > issues, but a lot of time it's ignorable, and deciding which is which is
> > fairly hard.  But used in situations where you are 100% sure exactly
> > what the images should look like, this can be quite effective.
>
> Yes, Pixman does the same separation. Some tests require bit-perfect
> results, others are kn