Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
sorry took so long. forgot to hit send... On 24/08/2013, at 1:04 AM, Stefan Schmidt wrote: > Hello. > > On 08/22/2013 10:43 PM, Lorn Potter wrote: >> Hi, >> I was told of this thread, perhaps I can make a few comments (sorry if it >> doesn't really follow the thread) >> [no knowing much about wayland protocol/api] >> >> first thoughts: >> >> * why no timestamp info? > > Arg, that is sitting uncommitted here and thus not made it into the patch. > Each event now has > > >> * why no rate info? (not all apps need/want the same speed) > > That was requested before. I left it out initially for a) simply the first > proposal and b) not being sure all sensor subsystems offer this. > > As you did qtsensor maybe you can shed some light on this. What systems does > qtsensor support and do all of them offer rate? QtSensors supports different rates, if two processes request different rates, the hardware runs at fastest rate, and is downsampled for slower. Some sensors only fire off if an event is triggered (proximity). As well, not all hardware support the same rates. Some support a range of rates, some support only certain rates. > >> * a magnetometer is not a compass, nor does it describe motion. >> - it seems your 'compass' is really just a magnetometer. A compass >> entails a sensor fusion of sorts to return heading information in degrees. >> It uses a magnetometer (calibrated - which mostly means hard and soft iron >> distortions removed), accelerometer (smoothed for jitter - used for >> 'leveling' the mag readings), and declination information from somewhere >> (mostly gps or a location lookup table). >> Compass could return magnetic north, true north in degrees from the y axis >> of the device. > > Agreed, compass is more than just the ambient magnetic field reading so this > should be renamed. > >> Most importantly, what is the justification for sending sensor data >> through wayland? > > Because of requests I heard allow clients like games to use some type of > sensor as user input. We did not include the other sensors for exactly this > reason. They are still available through a subsytsem on whatever platform you > run. > > For the sensors that reflect user input in terms of moving the device people > asked for getting these through the wayland protocol. I'm not expecting this > to be the best solution for every app but they still can get their > informations from the subsystem. >> Another thing to consider is you might want to handle axis' rotation when >> the device is rotated. > > Indeed. > >> Other devices you might consider is like the leapmotion sensor. > > Interesting type. But unlikely that I would work on something like this > without actually having access for testing it. So I will concentrate on the > things I have. > > regards > Stefan Schmidt Lorn Potter QtSensors/QtSensorGestures/QtSystemInfo llornkcor technologies / Jolla Mobile ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 10:43 PM, Lorn Potter wrote: Hi, I was told of this thread, perhaps I can make a few comments (sorry if it doesn't really follow the thread) [no knowing much about wayland protocol/api] first thoughts: * why no timestamp info? Arg, that is sitting uncommitted here and thus not made it into the patch. Each event now has * why no rate info? (not all apps need/want the same speed) That was requested before. I left it out initially for a) simply the first proposal and b) not being sure all sensor subsystems offer this. As you did qtsensor maybe you can shed some light on this. What systems does qtsensor support and do all of them offer rate? * a magnetometer is not a compass, nor does it describe motion. - it seems your 'compass' is really just a magnetometer. A compass entails a sensor fusion of sorts to return heading information in degrees. It uses a magnetometer (calibrated - which mostly means hard and soft iron distortions removed), accelerometer (smoothed for jitter - used for 'leveling' the mag readings), and declination information from somewhere (mostly gps or a location lookup table). Compass could return magnetic north, true north in degrees from the y axis of the device. Agreed, compass is more than just the ambient magnetic field reading so this should be renamed. Most importantly, what is the justification for sending sensor data through wayland? Because of requests I heard allow clients like games to use some type of sensor as user input. We did not include the other sensors for exactly this reason. They are still available through a subsytsem on whatever platform you run. For the sensors that reflect user input in terms of moving the device people asked for getting these through the wayland protocol. I'm not expecting this to be the best solution for every app but they still can get their informations from the subsystem. Another thing to consider is you might want to handle axis' rotation when the device is rotated. Indeed. Other devices you might consider is like the leapmotion sensor. Interesting type. But unlikely that I would work on something like this without actually having access for testing it. So I will concentrate on the things I have. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 09:20 PM, Bill Spitzak wrote: Jason Ekstrand wrote: One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html and the ~42 replies. It seems wrong to me that the count is split into two parts. For instance if there are two accelerometers: 1. The fact that it is non-zero is stored in a bit in the seat description This is meant as a capability not a number of devices. Its the same with keyboards and such. 2. Whether it is 1, 2, 3, etc is in a different undefined api. It depends from how you look at this. Getting all sensor objects available when requesting a sensor type gives the client the number as well as the possibility to deal with it. You want and explicit API to get the number of sensors and request them manually? There have also been some worry about running out of bits in the seat flags, too. Why not have an api that takes a seat and returns a big list of every device and every event that each device can produce. Yes that seems big but it is on the order of thousands and would be sent in one big block, not as thousands of messages. I think the type of device can be determined from the set of events it produces, though I guess you can also put a type id on the device. Hmm, an idea to think about. I guess you also want to have keyboard, pointer, touch, etc converted to this? regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 04:07 PM, Jason Ekstrand wrote: Stefan, Thanks for working on this! You can thank me once I get this into a state where it gets accepted. ;) As one general comment (protocol comments below), we need to make sure that "normal" values are somewhere around 1 to 1000. The wl_fixed type provides 24 bits of integer and 8 bits of fractional precision. The units used below seemed reasonable to me. That said, I'm not 100% sure how this relates to the real world so it's worth a check. We should be fine but I made a node to check on this. On Thu, Aug 22, 2013 at 4:45 AM, Stefan Schmidt mailto:s.schm...@samsung.com>> wrote: Hello. On 08/22/2013 09:46 AM, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html and the ~42 replies. Will go through this when I'm back from vacation. Thanks for pointing it out. One option we have been pondering about was adding a simple uid when doing the get_compass, etc calls and re-use this uid later in the motion events to identify the correct sensor. When the compositor adds the various sensors clients would get a event for each and could keep track on how many compass sensors there are for example and call get_compass accordingly if it is interested in all of them. I don't know that there's any real benifit to having some uid traveling along with them rather than just getting multiple protocol objects. Protocol objects are cheap and libwayland will sort out the id for you. For instance, you could have an event get_compass to which the compositor replies with a series of compas events each of which contains a new wl_compass instance. That could fit my needs. Its a corner case but I want this proposal to at least allow for such things in the future. Anyone having a better/different idea on this? regards Stefan Schmidt PS: I'm on vacation next week. Will reply to review and comments the week after. Signed-off-by: Stefan Schmidt mailto:s.schm...@samsung.com>> --- protocol/wayland.xml | 175 ++__ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ + + + @@ -1297,6 +1300,63 @@ + + +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_accelerometer interface +
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 11:45 PM, Bryce W. Harrington wrote: On Thu, Aug 22, 2013 at 09:46:28AM +0100, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event Signed-off-by: Stefan Schmidt --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ devices"/> more keyboards"/> devices"/> + devices"/> + gyroscope devices"/> + accelerometer devices"/> @@ -1297,6 +1300,63 @@ + + +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. sp. 'send' s/b 'sent' + + + + + + +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. here too + + + + + + +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. here too + + + + + + + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description sp. 'an brief' s/b 'a brief' + of the error, for (debugging) convenience. + + + + + + In a multiseat configuration this can be used by the client to help @@ -1605,6 +1665,121 @@ + + + The wl_compass interface represents a compass + associated with a seat. + + + + + Sent to enable event receiving for the compass sensor. + + + + + + Sent to disable event receiving for the compass sensor. + + It stops event reporting to this client. Other clients might still + receive events. + + + + + sensor"> + Updated sensor data available from compass + + Measurement of the ambient magnetic field in the X, Y and Z axis. sp. 'axis' s/b plural 'axes' here I think... + + Coordinate system (device in portrait mode with screen facing upwards): + X axis goes from the left to the right side of the device + Y axis goes from the bottom of the screen to the top + Z axis goes from the back of the screen to the front of the screen + + + + + + + + + + The wl_gyroscope interface represents a gyroscope + associated with a seat. + + + + + Sent to enable event receiving for the gyroscope sensor. + + + + + + Sent to disable event receiving for the gyroscope sensor. + + It stops event reporting to this client. Other clients might still + receive events. + + + + + sensor"> + Updated sensor data available from gyroscope + + Measurement of the rate of rotation around X, Y and Z axis in degree per second. sp. 'degree' s/b 'degrees' + Values are observed in positive notation in the counter-clockwise direction. + + Coordinate system (device in portrait mode with screen facing upwards):
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
On Thu, Aug 22, 2013 at 09:46:28AM +0100, Stefan Schmidt wrote: > Treating some specific sensors as input devices. In particular > adding support for wl_compass, wl_gyroscope and wl_accelerometer here. > > Using these sensor as input for apps and games. Not covering any > background apps or services with this protocol. > > We have requests to start and stop sensor event receiving as well as > events to receive the different axis values for these sensors. > > V2: > o Add units to event arguments > o Define coordinate system > o Be more verbose on security policy in compositor and add error event > > Signed-off-by: Stefan Schmidt > --- > protocol/wayland.xml | 175 > ++ > 1 file changed, 175 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index d79..e35413c 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1251,6 +1251,9 @@ > > > > + > + > + > > > > @@ -1297,6 +1300,63 @@ > > > > + > + > +The ID provided will be initialized to the wl_compass interface > + for this seat. > + > +This request only takes effect if the seat has the compass > +capability. If the seat has the capability but no object is > +received it could be that the compositor security policy has > +denied the sensor access for the client. In case of a security > +policy error an error event will be send. sp. 'send' s/b 'sent' > + > + > + > + > + > + > +The ID provided will be initialized to the wl_gyroscope interface > + for this seat. > + > +This request only takes effect if the seat has the gyroscope > +capability. If the seat has the capability but no object is > +received it could be that the compositor security policy has > +denied the sensor access for the client. In case of a security > +policy error an error event will be send. here too > + > + > + > + > + > + > +The ID provided will be initialized to the wl_accelerometer interface > + for this seat. > + > +This request only takes effect if the seat has the accelerometer > +capability. If the seat has the capability but no object is > +received it could be that the compositor security policy has > +denied the sensor access for the client. In case of a security > +policy error an error event will be send. here too > + > + > + > + > + > + > + The error event is sent out when a fatal (non-recoverable) > + error has occurred. The object_id argument is the object > + where the error occurred, most often in response to a request > + to that object. The code identifies the error and is defined > + by the object interface. As such, each interface defines its > + own set of error codes. The message is an brief description sp. 'an brief' s/b 'a brief' > + of the error, for (debugging) convenience. > + > + > + > + > + > + > > > In a multiseat configuration this can be used by the client to help > @@ -1605,6 +1665,121 @@ > > > > + > + > + The wl_compass interface represents a compass > + associated with a seat. > + > + > + > + > + Sent to enable event receiving for the compass sensor. > + > + > + > + > + > + Sent to disable event receiving for the compass sensor. > + > + It stops event reporting to this client. Other clients might still > + receive events. > + > + > + > + > + > + Updated sensor data available from compass > + > + Measurement of the ambient magnetic field in the X, Y and Z axis. sp. 'axis' s/b plural 'axes' here I think... > + > + Coordinate system (device in portrait mode with screen facing upwards): > + X axis goes from the left to the right side of the device > + Y axis goes from the bottom of the screen to the top > + Z axis goes from the back of the screen to the front of the screen > + > + > + > + > + > + > + > + > + > + The wl_gyroscope interface represents a gyroscope > + associated with a seat. > + > + > + > + > + Sent to enable event receiving for the gyroscope sensor. > + > + > + > + > + > + Sent to disable event receiving for the gyroscope sensor. > + > + It stops event reporting to this client. Other clients might still > + receive events. > + > + > + > + > + > + Updated sensor data available from gyroscope > + > + Measurement of the rate of rotation around X, Y and Z axis in degree > per second. sp. 'degree' s/b 'degrees' > + Values are observed in positive notation in the counter-clockwise > direction. > + > + Coor
[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hi, I was told of this thread, perhaps I can make a few comments (sorry if it doesn't really follow the thread) [no knowing much about wayland protocol/api] first thoughts: * why no timestamp info? * why no rate info? (not all apps need/want the same speed) * a magnetometer is not a compass, nor does it describe motion. - it seems your 'compass' is really just a magnetometer. A compass entails a sensor fusion of sorts to return heading information in degrees. It uses a magnetometer (calibrated - which mostly means hard and soft iron distortions removed), accelerometer (smoothed for jitter - used for 'leveling' the mag readings), and declination information from somewhere (mostly gps or a location lookup table). Compass could return magnetic north, true north in degrees from the y axis of the device. Most importantly, what is the justification for sending sensor data through wayland? Another thing to consider is you might want to handle axis' rotation when the device is rotated. Other devices you might consider is like the leapmotion sensor. Lorn Potter QtSensors/QtSensorGestures/QtSystemInfo llornkcor technologies / Jolla Mobile ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Jason Ekstrand wrote: One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html and the ~42 replies. It seems wrong to me that the count is split into two parts. For instance if there are two accelerometers: 1. The fact that it is non-zero is stored in a bit in the seat description 2. Whether it is 1, 2, 3, etc is in a different undefined api. There have also been some worry about running out of bits in the seat flags, too. Why not have an api that takes a seat and returns a big list of every device and every event that each device can produce. Yes that seems big but it is on the order of thousands and would be sent in one big block, not as thousands of messages. I think the type of device can be determined from the set of events it produces, though I guess you can also put a type id on the device. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Stefan, Thanks for working on this! As one general comment (protocol comments below), we need to make sure that "normal" values are somewhere around 1 to 1000. The wl_fixed type provides 24 bits of integer and 8 bits of fractional precision. The units used below seemed reasonable to me. That said, I'm not 100% sure how this relates to the real world so it's worth a check. On Thu, Aug 22, 2013 at 4:45 AM, Stefan Schmidt wrote: > Hello. > > > On 08/22/2013 09:46 AM, Stefan Schmidt wrote: > >> Treating some specific sensors as input devices. In particular >> adding support for wl_compass, wl_gyroscope and wl_accelerometer here. >> >> Using these sensor as input for apps and games. Not covering any >> background apps or services with this protocol. >> >> We have requests to start and stop sensor event receiving as well as >> events to receive the different axis values for these sensors. >> >> V2: >> o Add units to event arguments >> o Define coordinate system >> o Be more verbose on security policy in compositor and add error event >> > > One thing I'm still missing is a way to handle more than one sensor per > type for the future. Input devices like the wii-remote with nunchuk comes > to mind. Having two separate accelerometers which still would be a the same > seat but could not be aggregated. > Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.htmland the ~42 replies. > > One option we have been pondering about was adding a simple uid when doing > the get_compass, etc calls and re-use this uid later in the motion events > to identify the correct sensor. When the compositor adds the various > sensors clients would get a event for each and could keep track on how many > compass sensors there are for example and call get_compass accordingly if > it is interested in all of them. > I don't know that there's any real benifit to having some uid traveling along with them rather than just getting multiple protocol objects. Protocol objects are cheap and libwayland will sort out the id for you. For instance, you could have an event get_compass to which the compositor replies with a series of compas events each of which contains a new wl_compass instance. > > Its a corner case but I want this proposal to at least allow for such > things in the future. > > Anyone having a better/different idea on this? > > regards > Stefan Schmidt > > PS: I'm on vacation next week. Will reply to review and comments the week > after. > > > Signed-off-by: Stefan Schmidt >> --- >> protocol/wayland.xml | 175 >> ++** >> 1 file changed, 175 insertions(+) >> >> diff --git a/protocol/wayland.xml b/protocol/wayland.xml >> index d79..e35413c 100644 >> --- a/protocol/wayland.xml >> +++ b/protocol/wayland.xml >> @@ -1251,6 +1251,9 @@ >> >> >> >> + >> + >> + >> >> >> >> @@ -1297,6 +1300,63 @@ >> >> >> >> + >> + >> +The ID provided will be initialized to the wl_compass interface >> + for this seat. >> + >> +This request only takes effect if the seat has the compass >> +capability. If the seat has the capability but no object is >> +received it could be that the compositor security policy has >> +denied the sensor access for the client. In case of a security >> +policy error an error event will be send. >> + >> + >> + >> + >> + >> + >> +The ID provided will be initialized to the wl_gyroscope interface >> + for this seat. >> + >> +This request only takes effect if the seat has the gyroscope >> +capability. If the seat has the capability but no object is >> +received it could be that the compositor security policy has >> +denied the sensor access for the client. In case of a security >> +policy error an error event will be send. >> + >> + >> + >> + >> + >> + >> +The ID provided will be initialized to the wl_accelerometer >> interface >> + for this seat. >> + >> +This request only takes effect if the seat has the accelerometer >> +capability. If the seat has the capability but no object is >> +received it could be that the compositor security policy has >> +denied the sensor access for the client. In case of a security >> +policy error an error event will be send. >> + >> + >> + >> + >> + >> + >> + The error event is sent out when a fatal (non-recoverable) >> + error has occurred. The object_id argument is the object >> + where the error occurred, most often in response to a request >> + to that object. The code identifies the error and is defined >> + by the object interface. As such, e
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 09:46 AM, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. One option we have been pondering about was adding a simple uid when doing the get_compass, etc calls and re-use this uid later in the motion events to identify the correct sensor. When the compositor adds the various sensors clients would get a event for each and could keep track on how many compass sensors there are for example and call get_compass accordingly if it is interested in all of them. Its a corner case but I want this proposal to at least allow for such things in the future. Anyone having a better/different idea on this? regards Stefan Schmidt PS: I'm on vacation next week. Will reply to review and comments the week after. Signed-off-by: Stefan Schmidt --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ + + + @@ -1297,6 +1300,63 @@ + + +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description + of the error, for (debugging) convenience. + + + + + + In a multiseat configuration this can be used by the client to help @@ -1605,6 +1665,121 @@ + + + The wl_compass interface represents a compass + associated with a seat. + + + + + Sent to enable event receiving for the compass sensor. + + + + + + Sent to disable event receiving for the compass sensor. + + It stops event reporting to this client. Other clients might still + receive events. + + + + + + Updated sensor data available from compass + + Measurement of the ambient magnetic field in the X, Y and Z axis. + + Coordinate system (device in portrait mode with screen facing upwards): + X axis goes from the left to the right side of the device + Y axis goes from the bottom of the screen to the top + Z axis goes from the back of the screen to the front of the screen + + + + + + + + + + The wl_gyroscope interface represents a gyroscope + associated with a seat. + + + + + Sent to enable event receiving for the gyrosc
[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event Signed-off-by: Stefan Schmidt --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ + + + @@ -1297,6 +1300,63 @@ + + +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + + + + + + + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description + of the error, for (debugging) convenience. + + + + + + In a multiseat configuration this can be used by the client to help @@ -1605,6 +1665,121 @@ + + + The wl_compass interface represents a compass + associated with a seat. + + + + + Sent to enable event receiving for the compass sensor. + + + + + + Sent to disable event receiving for the compass sensor. + + It stops event reporting to this client. Other clients might still + receive events. + + + + + + Updated sensor data available from compass + + Measurement of the ambient magnetic field in the X, Y and Z axis. + + Coordinate system (device in portrait mode with screen facing upwards): + X axis goes from the left to the right side of the device + Y axis goes from the bottom of the screen to the top + Z axis goes from the back of the screen to the front of the screen + + + + + + + + + + The wl_gyroscope interface represents a gyroscope + associated with a seat. + + + + + Sent to enable event receiving for the gyroscope sensor. + + + + + + Sent to disable event receiving for the gyroscope sensor. + + It stops event reporting to this client. Other clients might still + receive events. + + + + + + Updated sensor data available from gyroscope + + Measurement of the rate of rotation around X, Y and Z axis in degree per second. + Values are observed in positive notation in the counter-clockwise direction. + + Coordinate system (device in portrait mode with screen facing upwards): + X axis goes from the left to the right side of the device (Pitch) + Y axis goes from the bottom of the screen to the top (Roll) + Z axis goes from the back of the screen to the front of the screen (Azimuth/Yaw) + + + + + + + + + + The wl_accelerometer interface represents a accelerometer + associated with a seat. + + + + + Sent to enable event r
