"dumb" clients also include X11 clients for legacy Xwayland compatibility. Of which there a lot of. <div class="gmail_quote">On Mar 16, 2015 8:35 PM, "microcai" <<a href="mailto:microcai@fedoraproject.org">microcai@fedoraproject.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">on Monday 16 March 2015 20:28:48，Daniel Stone wrote： > Hi, > > On 16 March 2015 at 00:35, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > On Tue, Mar 10, 2015 at 12:00 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote: > >> [blah blah blah] > >> > >> Events seem to be ok, but my complaint is that a large number of > >> coordinates in the api other than events are in integer logical pixels, > >> not in high dpi or in fixed-point. The offsets to attach are the biggest > >> culprits. There are also integer clip rectangles in the subsurface and > >> scaling apis. Except for compatibility there is no reason positions in > >> messages cannot be in buffer pixels. > > 'Except for compatibility', yeah. That's like saying that there's no > reason for me to have a job, except for the need to house and feed > myself. Kind of a showstopper, that. > > Smart clients do not require buffer scaling. The scaling is there as a > fallback to make clients who are blissfully unaware of the constraints > of high-DPI screens still work: no more, no less. Clients who have the > smarts to deal with resolution/DPI-independence will _already_ be > doing smart layout which avoids the need for buffer scaling. any client *has to be* smart client anyway. buffer scalling is such pointless. > > Any talk of throwing away buffer scaling (breaking dumb clients) in > order to fit the uses of clients who already today avoid buffer > scaling, is utterly pointless. Any attempt to handwave away the > disadvantages as nonexistent is disingenuous. > > > Please do not take a thread started by someone who is obviously > > confused and side-track it into a discussion of things that you think > > are design-flaws in the current protocol. This is not the appropriate > > place for a discussion of wl_surface.attach (x, y) coordinate systems > > and bringing that up only adds to the confusion. > > Yes, exactly. > > Yet again, this is something you have repeatedly brought up every time > something even tangentially related is mentioned. You've explained > your concerns over and over, and it's obvious that our opinions differ > and upstream will not change. Doing this makes it infinitely less > likely that your concerns will be taken seriously (cf. the > wl_keyboard_grab bug): the first reaction to seeing your name come up > in a thread is 'oh god, not again'. Which is a shame, as you do have > valuable input to offer, but it's drowned out by the amount that you > bang on about your pet peeves, with a total inability to accept that > someone with a differing opinion may just have a different opinion, > not be objectively wrong. Everyone loses: you don't get taken > seriously, we get frustrated, discussions get derailed, and people who > don't know better mistake your loud pronouncements for upstream's > actual position (or, when those differ from measurable reality rather > than opinion, a useful fact). > > Be the signal, not the noise. > > Cheers, > Daniel </blockquote></div>