On 11/12/2015 10:52 AM, Stefan Schmidt wrote: > Hello. > > On 12/11/15 16:48, Christopher Michael wrote: >> On 11/12/2015 10:43 AM, Stefan Schmidt wrote: >>> Hello. >>> >>> On 12/11/15 16:34, Christopher Michael wrote: >>>> With regard to the issues in ecore_wl_input ... >>>> >>>> I took a look at the expected callback of the wl_seat_listener, and >>>> the function that we have setup for that is proper (wrt function >>>> params, etc)...so I am unsure why this is complaining about an >>>> incorrect type... >>>> >>> >>> Had a quick look myself. The wayland header declare capabilities as >>> uint32_t while you use and enum. Which might be different when being on >>> 64bit? I'm honestly not sure for enum, would have to look it up. >>> >>> Ah, wait it says "incompatible argument 3 (different signedness)" so it >>> seems a problem with enum being seen as signed here. >>> >>> regards >>> Stefan Schmidt >>> >> >> Ahh, that would make sense then. I'm unsure wrt enum on 64bit also. I >> cross-referenced with the current weston implementation and they are >> also using enum...so this could be one of those things where 32 vs >> 64bit is making it complain ? ... >> >> I'm open to suggestions wrt how to deal with this ? Should we just >> leave it as is (according to spec) ? Should we change it to fix the >> signedness ?? Should we just ignore this warning ? >> > > Looking at enum wl_seat_capability from wayland I would say we are fine > as is. It only uses 1, 2 and 4 which means unsigned and no problems with > overflows or such. Just ignoring it would be safe here. > > regards > Stefan Schmidt >
Sounds like a good idea to me ;) Cheers, dh ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
