Re: [PATCH libinput 0/5] Disable laptop touchpad on lid close

[James Ye]

On Thu, Jan 5, 2017 at 4:15 PM, James Ye  wrote:
Although a laptop touchpad is usually not accessible when the lid is 
closed,
some laptop models suffer from a hardware bug where the touchpad can 
be
activated even if the lid is closed.  This bug can be worked around 
by disabling

the touchpad when the lid is closed.

This patch set adds:
1: hwdb patch to mark switches as input devices (needs to go to 
systemd)

2: switch interface[1]
3: evdev dispatch interface for laptop lid switches
4: mechanism for pairing touchpad with lid, and disabling the touchpad
5: test cases

Best regards,
James Ye


I did a bit of testing on a laptop which suffers from this issue.
The good news is that it works as intended on a real device, which
is expected.  The bad news, however, is that on that laptop
(ASUS ZENBOOK UX32VD) the lid switch does not reliably engage when
you close the lid.  The hardware design is similar across a few models
from that generation of laptops, so other models may be affected too.

In any case, I'll send in revised patches which fix some incorrect
assumptions about events soon.

Cheers,
 James




[1]: 
https://lists.freedesktop.org/archives/wayland-devel/2016-January/026349.html


James Ye (5):
  udev: mark switches as input devices
  Add a "switch" interface for parts of the SW_* range
  Add evdev_dispatch interface for lid switch
  Pair touchpad and lid_switch for disable
  test: add tests for lid switch

 doc/Makefile.am|   1 +
 doc/switches.dox   |  13 +++
 src/evdev-mt-touchpad.c|  47 
 src/evdev-mt-touchpad.h|   5 +
 src/evdev.c|  92 ++-
 src/evdev.h|   8 ++
 src/libinput-private.h |   5 +
 src/libinput.c | 103 +
 src/libinput.h | 107 +
 src/libinput.sym   |   9 ++
 test/Makefile.am   |   4 +-
 test/lid.c | 228 
+

 test/litest-device-lid-switch.c|  58 ++
 test/litest.c  |  31 +
 test/litest.h  |  10 ++
 tools/event-debug.c|  34 ++
 udev/90-libinput-model-quirks.hwdb |   6 +
 17 files changed, 758 insertions(+), 3 deletions(-)
 create mode 100644 doc/switches.dox
 create mode 100644 test/lid.c
 create mode 100644 test/litest-device-lid-switch.c

--
2.9.3



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

Re: [PATCH libinput v2 3/5] Add evdev_dispatch interface for lid switch

[jye836]

On Thu, Jan 12, 2017 at 2:21 PM, Peter Hutterer 
 wrote:
doh. not sure how I missed this in the first one, but this needs an 
extra
check for the event code too, otherwise we'll be sending switch lid 
events

for any switch on the device.

We filter for SW_LID but if a device happens to have switch and 
tablet mode
on the same node, then we do the wrong thing here. So I'd say, the 
easiest
here is have a lid_switch_process_switch() for EV_SW and move that 
condition
into a switch() statement in there (similar-ish to what the touchpad 
code

does for example).

I'm also relatively hesitant to merge the tablet mode switch enum 
value

unless we have an implementation for it. That's easy to remove though.


I agree with this.  The states I have given it are supposed to be 
consistent
with the lid switch, but I don't know if it's different in any actual 
tablet
mode switches in the wild.  That being said, it's just as easily added 
as it

is removed, so I'll remove it for now.

Cheers,
 James



the rest is good now, thanks.

Cheers,
   Peter


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

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen  said:

> On Fri, 13 Jan 2017 16:37:57 +0100
> Florian Höch  wrote:
> 
> > Am 13.01.2017 um 16:19 schrieb Richard Hughes:
> > > On 13 January 2017 at 14:56, Florian Höch 
> > > wrote:  
> > >> .. also guarantee that nothing else will be shown on that specific
> > >> output  
> > > 
> > > FWIW, I'd be fine just displaying a color swatch on the entire screen
> > > with no window decorations; the only reason we use a composited window
> > > in gnome-color-manager is so the user knows where the put the sensor.  
> > 
> > Well, that will work for profiling, as long as you don't mind not being
> > able to see progress information (which I would consider a real drawback).
> > Besides it's surely a bit awkward that the computer then cannot be as
> > easily used differently in the meantime if it doesn't have a second
> > monitor connected (not that I'd recommend it, but I often have a music
> > player open during measurements and sometimes it's nice to have the
> > ability to adjust the playlist while lengthy measurements are still
> > running, to give an example. Also who am I to tell people with their new
> > gigantic 4K 40" desktop monitor that they can't use the rest of the
> > available real estate while a comparatively tiny measurement swatch is
> > displayed in the center?).
> > Also a fullscreen color swatch will probably not be able to deal
> > gracefully with things like OLED screens which might have automatic
> > power limiting depending on displayed content and such, which could
> > botch the measurements in a way that makes the resulting profile useless.
> > 
> > It certainly won't work for guided adjustment (unless you re-implement
> > UI), where the feedback displayed in the UI is supposed to guide the
> > user through adjustments to (e.g.) monitor controls he/she needs to make.
> 
> Oh, ok, that's why. We could as easily have the compositor show the
> color swatch only on a part of the output and leave the rest of the
> area for normal use.
> 
> However, if that is done with a special protocol so that the compositor
> actually knows this is the profiling color swatch, it can make sure
> other windows cannot interfere. It could be like the color swatch was
> on an always-on-top overlay. You cannot do that any other way from a
> Wayland client.
> 
> And if unform color for the swatch is all you need, the protocol could
> simply take 3 numbers for the color instead of an image buffer. Then
> people would not get the urge to abuse this interface for e.g.
> application splash screens.

i kind of like the idea of a special protocol with 32bit ints per rgb etc. to
say "display this exact uncalibrated color as-is without luts or anything else
in the way"... but apply it to a separate toplevel window/surface (and put your
guided ui controls in another window) or... use a subsurface.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

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

Re: [RFC wayland-protocols] Color management protocol

[Benoit Gschwind]

Hello Graeme Gill

I read many comments on this topic including yours, and I agree with you 
about some points in particular about the calibration and profiling 
procedure, but I very puzzled by your position about some points. It's 
look like you hate display managers[1] because they are not able to 
produce accurate color from a given specification/definition/encoding.


I would like to point out that colorspace with pixel values is just an 
encoding for the color you would like produce on the monitor. That mean 
the compositor is capable to perform the translation to the monitor 
accurately as good as the given client application. He can do it even 
better because he has the hardware under-control and may have a wider 
community to support this feature.


I think you should drop the idea that the compositor cannot do something 
better than a specific application, by definition the compositor is an 
application.


Some comment about the reality you describe are following inline.

On 21/12/2016 01:08, Graeme Gill wrote:

Richard Hughes wrote:

On 20 December 2016 at 07:22, Graeme Gill  wrote:

Or be prepared to re-visit Wayland's fundamental design decisions
if they turn out to be based on a false premise.


I don't think that's fair. I think Wayland is the opportunity to upset
the status quo with color management and do correctly what what never
possible with X11.


I think it is fair - a lot of push back is along the lines of
"that's impossible - Wayland doesn't work that way", which
if taken to a logical conclusion, (maybe) implies that Wayland is
incapable of sporting color management.

Assumption: "Applications are oblivious to the output their
pixels are rendered to"

Reality: An application needs to know the output it's pixels
land on if it is to present them in the correct output specific
colorspace.


I disagree, an application need to know what they want show then they 
need a way to tell the compositor what they want. An application that 
want have a pixel in 40 cd.m-2 of red with wavelength 750 nm, must know 
how to tell that to compositor, it may be 240,2,4 RGB in the color space 
sRGB (totally random conversion). But once the encoding is agreed the 
compositor can do the same as any color-managed-aware software. In other 
hand I can agree that a client may want to know monitor capability to 
adapt their display, for example if the display isn't wide-gamut I just 
fallback to a normal gamut rendering, because rendering wide gamut is a 
waste of effort.


In any case please drop this reality. And help to define how the client 
should tell to the compositor which color he want to show, and what is 
useful to know for an application.




Assumption: "The compositor is able to do all the transformations
necessary to render applications pixels to the output device"

Reality: It may not be practical for a compositor to have the
color conversion machinery capable of doing the transformations
in the manner and to the precision that an application requires.



This reality is correct because you used 'MAY' but just assume the 
compositor can do all the transformations necessary to render 
applications pixels to the output device as good as any 
color-managed-aware software, even better because he will have a broader 
community. And also think that kind of transformation can probably be 
included in a library, which all compositors will be able to reuse. A 
little bit like libinput is currently used by a lot of compositor out-there.



Assumption: "Graphical system API's can be divided into
application operational API's, and Management API's.
Wayland need only cover the former".

Reality: Some graphical functions are both operational
for one type of application, and management for other types
of applications.


I do not understand this assumption, and obviously the related reality.



Assumption: "All management functions can be incorporated in
the compositor"

Reality: Some management functions require full blown applications,
and can't practically be incorporated in each compositor,
nor tailored to each compositor.

So if the realities challenge the assumptions, then
either clever means need to be invented to get things
to work within the assumptions, or the assumptions need
to be softened. Saying "it's impossible" doesn't progress
things, nor help bring Wayland up to having the capabilities
of other existing systems.

[ The above of course is, as best I grasp it from preceding
  conversations. ]


I agree with you, because I understand the context but out of context 
the assumption "All management functions can be incorporated in the 
compositor" is valid, nothing forbid any software to be included within 
a compositor, if you want a compositor with Tetris inside, it's up to 
you. That say I will explain why I agree with you: because I agree that 
it would be nice to split the software that find the calibration value 
and build profile from the compositor, and I think we 

Re: [RFC wayland-protocols] Color management protocol

[Benoit Gschwind]

Hello,

It's very difficult to contribute to this discussion, but here is my 
delta contribution.


I agree with the following proposal with comment bellow.

On 19/12/2016 09:27, Carsten Haitzler (The Rasterman) wrote:

On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill  said:



at this point i'm going to summarize this. this might be more helpful than
continuing point by point rebuttals as i sense that there's something missing
in this conversation:

summary of what i think should be the case (or roughly):

1. if colorspace/profile with buffer from client matches screen compositor
SHOULD do nothing with the pixels unless it has to (eg has to blend them with
content below or otherwise do effects etc. designated by its layout policy).
2. if null colorspace then compositors generally agree to ALSO not touch pixels
and transform them unless it has to blend them etc. like #1, but irrespective
of the output
3. if colorspace/profile does NOT match the display then compositor can either
a) transform colors to get them correct on another display or b) leave them
along and just leave things as they are and perhaps let the user know that the
colors for that window/surface may be wrong on that display, or limit the
screens that display that buffer based on context.

how to clients select a colorspace? compositor sends available colorspaces to
client (maybe send per surface actually?). client picks one and renders content
given that colorspace/profile and presents that to the compositor for display.
compositor may update colorspaces that are available at any time.

colorspaces/profiles should be nominal colorspace with a whole bunch of numbers
detailing adjustments/mappings to do exact color correction for that
colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with
different transform constants/gamma lut tables etc.



First this proposal do not cover the calibration and profiling 
procedure. This is about 'non-calibration clients' to use already used 
vocabulary, and I agree with the proposition to treat this topic 
independently of the calibration and profiling procedure.


The color space must be defined: color space define the link between the 
pixel value and the corresponding physical light property 
(Intensity/Luminescence, the mix of wavelength, ...?)[1]


To that proposal, I would add that the compositor should advertise the 
preferred color space. The definition of 'preferred' color space is 
implementation-defined (compositor-defined)[2]. For example a compositor 
may set the preferred color space to the color space that have the most 
accurate result, or the color space the most 'hardware' efficient 
(null-transform), or simply the user preferred color space[3]. He may 
not match any monitor color space.


We should also agree that surface that do not include color space 
specification should be null-transformed or maybe sRGB or something else 
(this is an open choice).


[1] I guess most color spaces are not defined as absolute light 
intensity but with relative intensity between a given black point and 
white point.


[2] I choose compositor-defined, because in case of multi-monitor it 
would be difficult to give a definition.


[3] I choose only one preferred color space instead of per monitor, 
because per-monitor color space, imply that client must known the 
monitor he belong.






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

Re: Schedule for 1.13 release

[Bryce Harrington]

Lets try that again:


Friday the 13th of January seems an auspiciously ominous time to
announce the schedule for 1.13.  So here's the upcoming dates:

  - 1.13-alpha around Jan 24th.  Major features done by this point.

  - 1.13-beta in first week of February.  

  - 1.13-rc1 around Feb 14th.

  - Additional rc's as needed.

  - 1.13.0 by Feb 21st at the earliest
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Schedule for 1.13 release

[Bryce Harrington]

Friday the 13th of January seems an auspiciously ominous time to
announce the schedule for 1.13.  So here's the upcoming dates:

  - 1.10-alpha around Jan 24th.  Major features done by this point.

  - 1.10-beta in first week of February.  

  - 1.10-rc1 around Feb 14th.

  - Additional rc's as needed.

  - 1.10.0 by Feb 21st at the earliest


signature.asc
Description: Digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Fri, Jan 13, 2017 at 9:03 AM, Pekka Paalanen  wrote:

> That's an excellent idea! Could you recommend some, so I don't pick a
> random "oh, but they're doing it wrong" video?

I'd say probably none of them are doing it wrong, but come with
editorialization of what's happening that they can't prove (and are
often wrong about ). So either watch it with the audio muted; or just
take their conclusions with a grain of salt. For example, I often hear
calibration as fixing course problems with a display, and profiling
fixes remaining inaccuracies after calibration. Wrong. Profiling is
just measuring and recording those measurements, it says nothing about
the rightness or wrongness of the display. It's just a bidirectional
lookup: RGB to XYZ (or Lab) and XYZ (or Lab) to RGB. The profile
itself does not change a display's behavior, it takes two or more
profiles to define a transform, and it's that transform that
(indirectly) moderates the display's behavior; or even the
application's behavior for that matter.



-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Monitor profiling (Re: [RFC wayland-protocols] Color management protocol)

[Chris Murphy]

On Fri, Jan 13, 2017 at 7:17 AM, Pekka Paalanen  wrote:

>
> If I understand right, the calibrating or monitor profiling process
> (are these the same thing?) needs to control the "raw" pixel values
> going through the encoder/connector (DRM terminology), hence you need
> access to the /last/ VideoLUT in the pipeline before the monitor. Right?
> Or not even a VideoLUT per se, you just want to control the values to
> the full precision the hardware has.

Calibration and characterization (profiling) are two distinctly
different things, that from a user perspective are blurred into single
event that's usually just called "display calibration" done by a
single program.

The software first linearizes the videoLUT (sounds like maybe there's
more than one in the hardware, but even from my technical perspective
we're only talking about such thing and I lack the hardware knowledge
to differentiate), then displays RGB test values while measuring their
response (photometer, colorimeter, spectroradiometer). Then a
correction curve is created by the software and applied to the
VideoLUT. This is calibration.

Next the software displays more RGB test values, subject to that video
LUT's correction, while measuring their response with either a
colorimeter or spectroradiometer. The software creates an ICC profile
from these measurements. This is characterization.


> How does the profiling work? I mean, what kind of patterns do you show
> on the monitor? All pixels always a uniform value? Or just some varying
> areas? Individual pixels? Patterns that are not of uniform color?

The test pattern needs to be large enough for the user to get the
measuring device aperture over the pattern without any ambiguity. The
test pattern is made of identical RGB values - although whether
dithering is used by the panel itself isn't something the software can
control, but is taken into account by the measuring device the same as
our visual system would.

The minimum test is black, white, each primary, and some number of
intermediate values of each channel to determine the tone response
curve (incorrectly called gamma but the shape of the curve could be
defined by a gamma function, or parametric function, or a table with
points). But each profiling software can do different things. There
are simple matrix + TRC only display profiles. And there are full 3D
LUT display profiles; these need more measurements, including more
than just measuring primaries - these include measurements of
secondary and tertiary colors.

Nearby to this test pattern, often there's some sort of status
indicator so the user has some idea the process hasn't stalled,
sometimes also including the RGB values being displayed and their
respective XYZ or Lab measured values (to some degree for
entertainment value I guess).

The ICC profile is used to do various transforms, e.g. CMYK to display
RGB, sRGB/Rec 709 to display RGB, etc. which is what's meant by
"display compensation" so the display produces colors as if it has a
behavior other than it's natural behavior. Those transforms are done
by ICC aware applications using a library such as lcms2. So whatever
pipeline is used for "calibration" needs to produce identical results
to the pipeline used by the application - otherwise all bets are off
and we'll get all kinds of crazy bugs that we will have no good way of
troubleshooting. In fact I'd consider it typical for me to display
sRGB 255,0,0 in say GIMP, and measure it with a colorimeter, and make
sure the XYZ values I get are identical to what the display ICC
profile says they should be. If not, I'm basically hosed. And I've
seen exactly this kind of bug before on every platform I've ever
tested and it's tedious to figure out.

Apple has a great little tool called Digital Color Meter that shows
the pixels on screen (digitally enlarged) so I can see what RGB values
it's sending to the display (these are post ICC transformed values,
but have not been additionally transformed by the video LUT, so in
reality these RGBs are not arriving at the panel but the video LUT
calibration + display are widely considered to be from the user and
even expert perspective to be one thing once the calibration is done).



>
> I would argue that it is much easier to make the above work reliably
> than craft a buffer of pixels filled with certain values, then tell the
> compositor to program the hardware to (not) mangle the values in a
> certain way, and assume the output is something you wanted. The
> application would not even know what manipulation stages the compositor
> and the hardware might have for the pixels, so you would still need a
> protocol to say "I want everything to be identity except for the last
> LUT in the pipeline". IMO that is a hell of a hard way of saying
> "output this value to the monitor".

OK. The only problem I see with two pipelines where one is described
as "much easier to make reliable" sounds like the other pipeline may
not be reliable, but 

Re: Monitor profiling (Re: [RFC wayland-protocols] Color management protocol)

[Benoit Gschwind]

On 13/01/2017 15:17, Pekka Paalanen wrote:


the calibrating or monitor profiling process (are these the same thing?)


As far as I know, no they are different, calibrating a monitor is the 
attempt to set cLUT and monitor setting to be close to a given target, 
often a given color space with a specific white/black point. Profiling 
is the characterization of the monitor (before or after calibration), 
i.e. you build a map from monitor signal to the color that the monitor 
actually show.


Combining both allow applications to correct the signal sent to the 
monitor to get as close as possible the desired physical color.


If I take a concrete example:

The calibration will try to make that (128,128,128) rgb tuple to be 
shown as a gray with half perceptual brightness than the white point, 
using cLUT or monitor settings.


While profiling will send (128,128,128) rgb tuple to the screen an 
measure the the actual color shown as physical luminescence, and store 
it in a file to allow future use for color correction.


Please correct me if I'am wrong.






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

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Fri, 13 Jan 2017 16:37:57 +0100
Florian Höch  wrote:

> Am 13.01.2017 um 16:19 schrieb Richard Hughes:
> > On 13 January 2017 at 14:56, Florian Höch  
> > wrote:  
> >> .. also guarantee that nothing else will be shown on that specific output  
> > 
> > FWIW, I'd be fine just displaying a color swatch on the entire screen
> > with no window decorations; the only reason we use a composited window
> > in gnome-color-manager is so the user knows where the put the sensor.  
> 
> Well, that will work for profiling, as long as you don't mind not being
> able to see progress information (which I would consider a real drawback).
> Besides it's surely a bit awkward that the computer then cannot be as
> easily used differently in the meantime if it doesn't have a second
> monitor connected (not that I'd recommend it, but I often have a music
> player open during measurements and sometimes it's nice to have the
> ability to adjust the playlist while lengthy measurements are still
> running, to give an example. Also who am I to tell people with their new
> gigantic 4K 40" desktop monitor that they can't use the rest of the
> available real estate while a comparatively tiny measurement swatch is
> displayed in the center?).
> Also a fullscreen color swatch will probably not be able to deal
> gracefully with things like OLED screens which might have automatic
> power limiting depending on displayed content and such, which could
> botch the measurements in a way that makes the resulting profile useless.
> 
> It certainly won't work for guided adjustment (unless you re-implement
> UI), where the feedback displayed in the UI is supposed to guide the
> user through adjustments to (e.g.) monitor controls he/she needs to make.

Oh, ok, that's why. We could as easily have the compositor show the
color swatch only on a part of the output and leave the rest of the
area for normal use.

However, if that is done with a special protocol so that the compositor
actually knows this is the profiling color swatch, it can make sure
other windows cannot interfere. It could be like the color swatch was
on an always-on-top overlay. You cannot do that any other way from a
Wayland client.

And if unform color for the swatch is all you need, the protocol could
simply take 3 numbers for the color instead of an image buffer. Then
people would not get the urge to abuse this interface for e.g.
application splash screens.


Thanks,
pq


pgpiPwxgunTef.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Fri, 13 Jan 2017 15:56:50 +0100
Florian Höch  wrote:

> [ Bunch of replies to different posts crammed into one, apologies in
> advance. ]
> 
> Pekka Paalanen wrote:
> > Would it not be simpler to just say "I'm doing calibration now, make
> > sure nothing interferes"?  
> 
> Sure, I just hope that "I'm doing calibration now, make sure nothing
> interferes" still allows conventional application UI (e.g. using UI
> frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
> effectively block users from interacting with said UI (going by your
> comment "I also forgot to mention that surfaces with the
> cms_calibration_surface role, when actually presented, would also
> guarantee that nothing else will be shown on that specific output"
> somehow sounds like it would not, but maybe I'm misunderstanding what
> you mean by "output". I would certainly not be enthused if I had to
> low-level re-implement parts of the UI I currently have - in fact I can
> tell you right now that it would never, ever happen if it's not as
> simple as writing for any of the common UI frameworks).

Hi,

my idea for a user story would be something like this:

- user starts a calibration app and clicks "profile output HDMI 2"

- optional: the compositor shows a dialog: "Application Foo wants to
  profile output HDMI 2. Allow / Deny ? You can press Esc to abort
  profiling after it starts."

- The output HDMI 2 gets filled with the profiling pattern according
  the application requests, and literally nothing else will show up on
  that output.

- If the user wants to abort the profiling run before it completes, he
  presses Esc, which the compositor grabs and restores HDMI 2 to normal.

- If the profiling finishes by itself, HDMI 2 is restored to normal
  automatically.

- The profiling application will know what happened in all cases.

How's that sound? I'm running blind here, because I've never used a
profiling app.

Would you really need the user to interact with the UI while the
profiling pattern is shown?

If you show any UI bits on the profiled output, how do you avoid the UI
affecting the profiling results? Keep in mind the window positioning
limitations in Wayland desktop.

Other outputs should remain normal during profiling, but of course
there might be only one output connected.

> Put bluntly, but I agree as well. A "calibration/profiling/measurement"
> application is not more of a "special-purpose client" than, say, a CAD
> application, a code editor, or an application that lets you create 3D
> scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.

Graeme just managed to explain to me why the profiling app needs access
to the VideoLUT (see [1]) which is a global resource. That makes the
profiling app a very special case on Wayland, because on Wayland we
very very carefully avoid unconditional access to such global
resources, so that apps cannot take the user or the desktop hostage or
mess it up even if they tried to(*). Changing the VideoLUT will mess up
all other windows on that output, and the profiling app will not even
tolerate any other windows on that output at the same time.

Any application you listed does not require similar access to a global
resource. A profiling app OTOH cannot use the normal content delivery
paths because as Graeme explained they often do not reach the full
precision without changing the VideoLUT.

Another example of where Wayland denies access to global resources is
that an application cannot make an input grab at will. Input grabs are
always conditional, and breakable. We should have similar behaviour
also with "screen grabs" like these.

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-January/032616.html

(*) The classic example of messing up the user's desktop is games
changing the X server video mode, and for one reason or another (don't
care, bug, broken, crashed) never restores it to original, or even if
it does restore, all your icons on the desktop get squashed in the
top-left corner. That is one reason why Wayland does not have a RandR
interface.


> Graeme Gill wrote:
> > I'm also thinking it would really help a lot if you and
> > others contributing to this thread were able
> > to procure something like a X-Rite i1 display Pro,
> > run up the manufacturer provided software on
> > MSWindows or OS X to get a feel for what it does,
> > then fire up DisplayCAL+ArgyllCMS on Linux/X11
> > and take it for a spin.
> > (Another path would be to obtain one of Richard's
> >  ColorHug's, but I think seeing how the commercial
> >  software operates as well, would add a broader perspective.)  
> 
> Even watching some videos of a typical calibration/profiling workflow on
> YouTube may already help.

That's an excellent idea! Could you recommend some, so I don't pick a
random "oh, but they're doing it wrong" video?


Thanks,
pq


pgpCzxcxoUwn1.pgp
Description: OpenPGP digital signature

Re: [RFC wayland-protocols] Color management protocol

[Florian Höch]

Am 13.01.2017 um 16:19 schrieb Richard Hughes:
> On 13 January 2017 at 14:56, Florian Höch  
> wrote:
>> .. also guarantee that nothing else will be shown on that specific output
> 
> FWIW, I'd be fine just displaying a color swatch on the entire screen
> with no window decorations; the only reason we use a composited window
> in gnome-color-manager is so the user knows where the put the sensor.

Well, that will work for profiling, as long as you don't mind not being
able to see progress information (which I would consider a real drawback).
Besides it's surely a bit awkward that the computer then cannot be as
easily used differently in the meantime if it doesn't have a second
monitor connected (not that I'd recommend it, but I often have a music
player open during measurements and sometimes it's nice to have the
ability to adjust the playlist while lengthy measurements are still
running, to give an example. Also who am I to tell people with their new
gigantic 4K 40" desktop monitor that they can't use the rest of the
available real estate while a comparatively tiny measurement swatch is
displayed in the center?).
Also a fullscreen color swatch will probably not be able to deal
gracefully with things like OLED screens which might have automatic
power limiting depending on displayed content and such, which could
botch the measurements in a way that makes the resulting profile useless.

It certainly won't work for guided adjustment (unless you re-implement
UI), where the feedback displayed in the UI is supposed to guide the
user through adjustments to (e.g.) monitor controls he/she needs to make.

-- 
Florian Höch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Richard Hughes]

On 13 January 2017 at 14:56, Florian Höch  wrote:
> .. also guarantee that nothing else will be shown on that specific output

FWIW, I'd be fine just displaying a color swatch on the entire screen
with no window decorations; the only reason we use a composited window
in gnome-color-manager is so the user knows where the put the sensor.

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

[RFC wayland-protocols] Color management protocol

[Florian Höch]

[ Bunch of replies to different posts crammed into one, apologies in
advance. ]

Pekka Paalanen wrote:
> Would it not be simpler to just say "I'm doing calibration now, make
> sure nothing interferes"?

Sure, I just hope that "I'm doing calibration now, make sure nothing
interferes" still allows conventional application UI (e.g. using UI
frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
effectively block users from interacting with said UI (going by your
comment "I also forgot to mention that surfaces with the
cms_calibration_surface role, when actually presented, would also
guarantee that nothing else will be shown on that specific output"
somehow sounds like it would not, but maybe I'm misunderstanding what
you mean by "output". I would certainly not be enthused if I had to
low-level re-implement parts of the UI I currently have - in fact I can
tell you right now that it would never, ever happen if it's not as
simple as writing for any of the common UI frameworks).

Graeme Gill wrote:
> Niels Ole Salscheider wrote:
>> My working view at the moment is that whatever is doing calibration
>> should be directly in charge of the full insane complexity of the
>> display hardware, and that even enumerating this, let alone offering
>> control over it, is not tractable. Which leaves us with two options:
>> the compositor runs calibration, or external calibration apps do not
>> run under a Wayland session and just drive DRM/KMS directly.
> 
> Really unattractive (i.e. a big obstacle) from a color management
> calibration/profiling application writers point of view.

Fully agree. On top of that, a "calibration/profiling/measurement"  app
is just a normal desktop application from a users' point of view, no
user will want or even expect such type of application to be any
different to what he/she is used to.

Graeme Gill wrote:
> Niels Ole Salscheider wrote:
>> This didn't make any sense when all display drivers were Xorg
>> components, but hey, we do have a universal API in DRM/KMS that you
>> can write applications directly towards, so I don't see why we should
>> bend over backwards making these compromises for special-purpose
>> clients which by definition do not interoperate with a regular desktop
>> environment.
> 
> Sorry, but from my perspective this is completely insane.
>
> I think that adding a couple of well understood API's doesn't
> compare to modifying a desktop application to have to, on the fly
> switch from a normal application context into configuring
> and then driving a (basically) raw frame buffer, convey all
> it's user interface to the frame buffer to run test patches,
> and then switch back again. And I don't know what you mean by
> "do not interoperate with a regular desktop environment". These
> are perfectly regular desktop applications that happen to have
> a special purpose. Casting them adrift from the normal desktop
> environment raises their difficulty into the "requires heroic effort"
> territory, due to huge breakage of cross platform application
> compatibility alone, and is directly contrary to the very
> idea of what a display server and the overlaying application UI
> toolkits are meant to provide!

Put bluntly, but I agree as well. A "calibration/profiling/measurement"
application is not more of a "special-purpose client" than, say, a CAD
application, a code editor, or an application that lets you create 3D
scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.

Graeme Gill wrote:
> I'm also thinking it would really help a lot if you and
> others contributing to this thread were able
> to procure something like a X-Rite i1 display Pro,
> run up the manufacturer provided software on
> MSWindows or OS X to get a feel for what it does,
> then fire up DisplayCAL+ArgyllCMS on Linux/X11
> and take it for a spin.
> (Another path would be to obtain one of Richard's
>  ColorHug's, but I think seeing how the commercial
>  software operates as well, would add a broader perspective.)

Even watching some videos of a typical calibration/profiling workflow on
YouTube may already help.

[ Apologies if this post comes across more negative than I wanted it to
be. I'm certainly willing though to exercise the necessary patience and
open-ness to learn about other perspectives. ]

--
Florian Höch

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

Monitor profiling (Re: [RFC wayland-protocols] Color management protocol)

[Pekka Paalanen]

Hi,

there is some controversy in whether this belongs in Wayland or not,
but if we assume that it does...


On Thu, 5 Jan 2017 12:40:08 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> 
> > Designing that is trivial:  
> 
> I'm not so sure.
> 
> > GLOBAL cms_calibrator
> > - request: create_calibration_surface(wl_surface, new 
> > cms_calibration_surface)
> > # Assigns wl_surface role.
> > 
> > INTERFACE cms_calibration_surface
> > # Surfaces with this role will only be shown on the set output,
> > # with direct color path bypassing all color-management, and
> > # and the hardware has been reset to neutral/identity settings.
> > # (or whatever requirements are appropriate, you can decide
> > # what to write here)  
> 
> Why this has to be made a special case? The normal
> machinery used to manage color is capable of
> configuring things to be in a proper state for calibration
> and profiling (if this was not the case, then it is not
> truly able to do the color management!)

So you say, but then you continue...

> Due to the different bit depth of the VideoLUT entries and the
> frame buffer, it is expected that it is possible to set
> the VideoLUT value for the entry that corresponds
> with the values set in the frame buffer (i.e. classically
> 10 bit VideoLUT entry depth in 8 bit frame buffer),
> so that the test patch values can be of the same precision
> as the resulting VideoLUT entries that get created from them.

...which is actually a very important detail. In other words, the
normal pixel path cannot be used for calibration, because it won't
usually have enough precision: the VideoLUT output has more bits than
the buffer pixels have.

So this is why you keep insisting that applications need to have access
to the VideoLUT. Finally.

However, controlling the output values does not imply access to the
VideoLUT - it's just the only way you have had so far.

If I understand right, the calibrating or monitor profiling process
(are these the same thing?) needs to control the "raw" pixel values
going through the encoder/connector (DRM terminology), hence you need
access to the /last/ VideoLUT in the pipeline before the monitor. Right?
Or not even a VideoLUT per se, you just want to control the values to
the full precision the hardware has.

How does the profiling work? I mean, what kind of patterns do you show
on the monitor? All pixels always a uniform value? Or just some varying
areas? Individual pixels? Patterns that are not of uniform color?

If it was enough to just light up all pixels of a monitor with one
specific color value at a time, we could pretty easily define a
calibration protocol that instead of using buffers and surfaces, you
would just tell which values to emit to the monitor. Then the
compositor, which is in charge of the hardware pipeline, can do the
right thing. We could encode the values in e.g. 32-bits per channel or
whatever you like, and there could be a provision for the compositor to
report actual number of bits used.

Plus all the needed guarantees of non-interfering like we discussed in
the other email, and an ack from the compositor when the new value has
actually reached the monitor.

I would argue that it is much easier to make the above work reliably
than craft a buffer of pixels filled with certain values, then tell the
compositor to program the hardware to (not) mangle the values in a
certain way, and assume the output is something you wanted. The
application would not even know what manipulation stages the compositor
and the hardware might have for the pixels, so you would still need a
protocol to say "I want everything to be identity except for the last
LUT in the pipeline". IMO that is a hell of a hard way of saying
"output this value to the monitor".

> And let me raise a fundamental point about profiling here
> (not to be confused with calibration). Profiling the display will not
> work if the color values of the pixels to the display is different during
> profiling, to what it is for normal application display.

Right.

(What is the difference between calibrating and profiling?)

In the scheme above, there would indeed be very different paths for
profiling vs. normal usage. But I do think that is how it has to be,
they will always be different: normal usage will not have the
opportunity to change the VideoLUT at will.

You can still ensure the compositor works correctly. After you have
profiled the monitor, configured the compositor to use the new
profiles, you can use the normal usage path to show a test image and
verify that the colorimeter agrees.

I think one would want to do the verification step anyway, and with
various different content color... um, definitions(?) to see that the
compositor does indeed work correctly for more than one case.

I recall demands from earlier that there must be a "pass-through mode"
for pixels so that calibration apps can work. I think the design
described above provides that 

Re: [RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Thu, 5 Jan 2017 12:51:58 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> 
> > I also forgot to mention that surfaces with the cms_calibration_surface
> > role, when actually presented, would also guarantee that nothing else
> > will be shown on that specific output, screen saving will not activate,
> > etc. anything that might hamper calibration will not happen.  
> 
> That's all good - but aren't these the sorts of controls
> that other applications need too ?

Maybe, but not that way. Wayland is intended to have a semantic desktop
shell protocol where clients communicate exact intents, while X11 was a
purely mechanical protocol with no intents at all.

For instance, to fullscreen a window, in X11 you "set position, set
size, stack on top" (wait, what position? what size is appropriate?)
and the WM has to guess what you wanted. In Wayland, you "make me
fullscreen", and the WM will know exactly what you want and it will do
exactly what you need and it can even tell you what the appropriate
size is, so no-one has to guess anything.

Yes, X11 actually has the NET_WM fullscreening protocol added later by
EWMH IIRC. It communicates intent.

> Slide show or Video player apps need to prevent screensaving,
> modal dialogs need to be able to pop to the top of
> the window stack etc.

Preventing screensaving is a lot more complicated that you might first
think when integrated properly.

No application will be able to unconditionally steal your whole desktop
like traditional modal dialogs can, so there will not be such a
request, or it will be limited to the windows of the single client, or
a client-provided sub-set of windows. It would not help at all with a
calibration app. Similarly there is no "stack on top" unconditional
request, but there will likely be a "wants attention" request which
under the compositors policy may cause the window to be stacked on top.

And then the "etc.". Compositors may gain new features you have not
anticipated, that will interfere with calibration. How would you know
to write support for them all in your calibration app to disable them
one by one?

Would it not be simpler to just say "I'm doing calibration now, make
sure nothing interferes"?


Thanks,
pq


pgp3mdUJd40Og.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston: recommendations for implementing splashscreen in a custom shell?

[Daniel Stone]

Hi,

On 13 January 2017 at 11:42, Pekka Paalanen  wrote:
> Weston's desktop-shell uses an event from the helper client to signal
> when it is ready, and fades in only after that (if the fade-in
> animation is enabled). I understand you want to keep the boot splash
> image instead, but keep that event in mind.
>
> I think it should be possible for Weston to scrape the current image on
> an active output when it starts up, but so far it has not been
> implemented. I have a vague recollection that something with the Xorg
> server (the video DDXen?) might do a similar thing, if you need an
> example.
>
> If you actually manage to scrape the original boot splash, you can have
> Weston keep showing it until your helper client is ready to take over.
>
> It might even be as simple as postponing Weston's first modeset until
> the helper client is ready, since existing screen contents should stay
> put until then, IIRC.

I'd be 100% in favour of this approach: delaying the original modesets
until the shell indicates that the scene graph as it stands is totally
quiescent. I'm working along those lines as we speak for atomic
anyway: we need to do one single modeset covering all outputs, rather
than individually. I'll try to keep that in mind when doing that and
CC you both on the patch which actually implements that.

(Skip the following paragraph if you don't care about KMS details.)

The reason I need to is because currently, we schedule every output
repaint independently, which sets the configuration for that output
only. With the old drmModeSetCrtc API, moving a connector to a CRTC
was possible in a single hop: if you started with CRTC A -> connector
B and CRTC Y -> connector Z, then Weston decided to use CRTC A ->
connector Z and CRTC Y -> connector B, you could do this with one
call. Setting CRTC A would disable CRTC Y as its connectors had
disappeared. With atomic, you need to explicitly add CRTC Y in, rather
than it implicitly being disabled. I'd mostly managed to steer clear
of it, but this week something changed such that Mutter and the kernel
pick a different CRTC/connector pairing than Weston does.

We can hack around this by trying to keep an existing CRTC/connector
pairing where possible, which is desirable for performance reasons if
nothing else anyway. But we do need to switch to a single atomic
modeset for all outputs, not just for performance but also so we can
perform reconfigurations which were previously not possible in
intermediate steps.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: App GUI positioning in Desktop-shell for weston

[Pekka Paalanen]

On Wed, 28 Dec 2016 18:58:23 +0530
Ajmal  wrote:

> -Original Message-
> From: "Ajmal" 
> Sent: ‎28-‎12-‎2016 06:53 PM
> To: "wayland-devel@lists.freedesktop.org" 
> 
> Subject: App GUI positioning in Desktop-shell for weston
> 
> Hai,
> 
> I am trying to run an application on Weston desktop shell. I am using
> 3 shared displays. Everytime I try to run the app, the GUI comes at a
> different position. How can I control this. In ivi shell I am able to
> control the layer and surface using LayerManagerControl. Is there a
> similar mechanism in desktop shell? How do I position my app in the
> desired display at a particular position of my choosing? I am just
> starting with Weston. Please help

Hi,

there is no desktop protocol extension to do that currently.


Thanks,
pq


pgpJ_PHaWb8ka.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston: recommendations for implementing splashscreen in a custom shell?

[Pekka Paalanen]

On Fri, 30 Dec 2016 15:07:38 -0600
Matt Hoosier  wrote:

> Hi,
> 
> I maintain a small Weston shell plugin for an an embedded use-case. On the
> embedded device, the bootloader first paints a buffer and installs it as
> the scanout buffer to the graphics hardware. At some point, userspace has
> to take over responsibility for painting that background image. It seems to
> make sense for that to be the compositor's job (in the shell plugin), since
> it's in complete control of the ordering of surfaces shown by the
> compositor.
> 
> Currently, my Weston shell plugin delegates the responsibility for painting
> the userspace version of the splashscreen to a well-known client program
> spawned internally from the shell plugin. This is similar in style to the
> way that desktop-shell has a child process paint its background image. But
> this approach ends up leading to a race condition: there's a momentary
> flicker when the compositor has nothing but its default background to paint
> because there are not yet any clients.This flickering phase comes to an end
> when the process I spawned to paint the splashscreen image finishes
> initializing and posts its first wl_buffer to the compositor. It's brief,
> but the window of time during which the bootloader-provided splash is
> overwritten by the (blank) default compositor output, is easily noticeable.
> 
> Is there an accepted technique for arranging that rich graphic content
> (something loaded from a PNG or similar) can be available at the first
> moment the compositor draws a frame and assumes responsibility for the DRM
> hardware's contents? Perhaps:
> 
> * Directly instantiate Weston data structures such as weston_view and
> weston_surface equivalent to what would have been done by a Wayland client
> program, and hook them into the layer list? This seems to run into problems
> about needing wl_client's and wl_resource's that really properly only come
> from a client attached to the compositor.
> 
> * Keep the splash-image painting and buffer posting all in a child process,
> but somehow delay the return of the shell plugin's module_init() function
> until I observe the client post a buffer? This seems prone to deadlocking.

Hi,

indeed you have identified the problems with your ideas.

Weston's desktop-shell uses an event from the helper client to signal
when it is ready, and fades in only after that (if the fade-in
animation is enabled). I understand you want to keep the boot splash
image instead, but keep that event in mind.

I think it should be possible for Weston to scrape the current image on
an active output when it starts up, but so far it has not been
implemented. I have a vague recollection that something with the Xorg
server (the video DDXen?) might do a similar thing, if you need an
example.

If you actually manage to scrape the original boot splash, you can have
Weston keep showing it until your helper client is ready to take over.

It might even be as simple as postponing Weston's first modeset until
the helper client is ready, since existing screen contents should stay
put until then, IIRC.

In any case, I believe it requires some work with the DRM-backend
and/or libweston core. I think it might be nice to add a libweston
function that the shell code needs to call before a backend actually
starts driving the outputs. I can't say off-hand how that
implementation should look like, though.

Scraping the original boot picture would only be necessary if one
wanted to do e.g. a cross-fade to the desktop.


Thanks,
pq


pgpNeFcSsXS8o.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Did Wayland Release Schedule change ?

[Ucan, Emre (ADITG/SW1)]

Hi,

The last release v1.12 is released  on September 2016.
I expected that the v1.13 will be released on Jan 2017.
But there are no ongoing release activities, e.g. release candidate tags etc.

Did wayland release schedule change ?

Best regards

Emre Ucan
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libinput 1.5.4

[Peter Hutterer]

libinput 1.5.4 is now available. Patches included are a few fixes with the
help output in the tools and improved disable-while-typing. If fingers
aren't moving at the beginning of a gesture, we try to detect the gesture
based on the finger position. Finally, the Asus X555LAB has a reduced middle
button size (because it has a visual marker anyway). Nothing exciting, but
feel free to celebrate regardless.

This is the last 1.5.x release unless some major bug comes up.

Peter Hutterer (11):
  tools: support --help in the ptraccel-debug tool
  tools: add some extra help output about the expected input data
  test: mark the magic trackpad as external in udev
  test: use the udev property to check for external/internal touchpads
  touchpad: if an external touchpad and keyboard share a VID/PID assume dwt
  gestures: if fingers don't move, force a gesture by finger position
  tools: add allowed range to --set-speed help output
  Remove a couple of double semicolons
  touchpad: add a model tag to mark touchpads with visible marker
  udev: mark Asus X555LAB as touchpad with visible marker
  configure.ac: libinput 1.5.4

git tag: 1.5.4

https://www.freedesktop.org/software/libinput/libinput-1.5.4.tar.xz
MD5:  e9c9975487b8a1885a8a864c40bf26be  libinput-1.5.4.tar.xz
SHA1: 36800caa5c89b2e932f094ed18691591c4d0  libinput-1.5.4.tar.xz
SHA256: 6f9ad1ede468bd54ec4469b8a4eb93a6f62f7fe6480c7a43e36c5d58cc2822b7  
libinput-1.5.4.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.5.4.tar.xz.sig



signature.asc
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel