Patent Description:
<CIT> discloses a multi-display device adapted to turn on and off certain device functionality based on one or more of device state and triggers. The triggers include a transition trigger, an open trigger and a closed trigger. Furthermore, and based on one or more of these triggers and device state, the device can provide feedback to a user, such as visual feedback, audio feedback and vibration feedback to assist a user with determining when the device is changing state. The operation of the primary screen, secondary screen, system and feedback options are also described relative to the beginning and endpoint of the device transition. The trigger corresponding to a transitional trigger where primary and secondary screens have a certain angle orientation and the trigger corresponding to a trigger point where the primary and secondary screens have a second angle orientation relative to one another are described.

"<NPL> contains useful information applying to this product, and helps you to be more productive, This guide contains detailed information on such subjects as systems utilities, data recovery, expansion options and troubleshooting.

<CIT> discloses a method for controlling a portable device including first and second display units at opposing surfaces of the portable device. The method includes detecting one of a first unlock command for switching a state of the first display unit to an active state and maintaining a state of the second display unit in a locked state or a second unlock command for switching the state of the first display unit to the active state and switching the state of the second display unit to a ready-to-activate state; switching the state of the first display unit to the active state and switching the state of the second display unit to the ready-to-activate state when the second unlock command is detected; detecting an unlock trigger for switching the second display unit, which is in the ready-to-activate state, to the active state; and switching the second display unit, which is in the ready-to-activate state, to the active state according to the detected unlock trigger.

<CIT> discloses a portable device and a method for controlling the same. The portable device comprises a double sided display unit including a first display screen on a front side and a second display screen on a back side; a first touch sensor unit and a second touch sensor unit configured to respectively sense a first touch input for the first display screen and a second touch input for the second display screen; and a processor configured to switch the second touch sensor unit to a ready-to-active state activating temporarily the second touch sensor unit for a predetermined period when the first touch input for the first display screen is sensed, and switch the second touch sensor unit to an active state when the second touch input for the second display screen is sensed within the predetermined period.

<CIT> discloses a display device including a first display panel having a first display area, a second display panel having a second display area, an arithmetic circuit which controls a display status of the first display panel and a display status of the second display panel, and a sensor which detects a spatial movement of the display device, in which the arithmetic circuit changes a display mode of images displayed by the first display panel and the second display panel based on a detection result by the sensor.

<CIT> discloses an apparatus to control power consumption including hardware logic to determine whether an electronic device is using an external display, determine whether a user input has been received by the electronic device within a predetermined time period when the electronic device is using the external display, and control power consumption by a display of the electronic device based at least in part on whether user input has been received within the predetermined time period.

According to aspects of the present invention there is provided a system and a method as defined in the accompanying claims. Techniques for configuration of primary and secondary displays are described. In one or more implementations, an apparatus such as a mobile device includes multiple interconnected display devices that can be configured in different ways, such as output primary, input primary, sensor primary, and so forth. At least one implementation enables different zones of a single display surface to be configured as primary and secondary for different purposes, such as input and/or output.

Entities represented in the figures may be indicative of one or more entities and thus reference may be made interchangeably to single or plural forms of the entities in the discussion.

Techniques for configuration of primary and secondary displays are described. In one or more implementations, an apparatus such as a mobile device includes multiple interconnected display devices. The apparatus, for instance, includes two (or more) display devices connected by a hinge such that the display devices can be positioned at different angles relative to one another. Generally, this supports different usage scenarios of the apparatus. An apparatus with multiple display devices introduces a number of challenges from a resource usage perspective. For instance, multiple display devices typically draw more power to drive the display devices than does a single display device. Further, multiple display devices typically utilize more computing resources than single devices, such as processor bandwidth and memory to manage input and output to multiple display devices in contrast with a single display device. Techniques described herein mitigate these issues.

For instance, techniques described herein enable display devices on a multi-display client device to be configured in various ways. For instance, based on a determined state condition of the client device, a first display device is designated as output primary, and a second display device is designated as output secondary. The output primary display is optimized for visual output, such as by maintaining a higher display brightness and/or resolution for the output primary display than for the output secondary display. This conserves power and battery life by reducing power utilization by the output secondary display.

As further described below, display devices on a multi-display client device can also be designated as input primary and input secondary, and/or sensor primary and sensor secondary. Generally, this causes a display device that is designated as input/sensor primary to be optimized for user input and/or sensor input, and reduces power and processor usage of an input/sensor secondary display by reducing power and processor bandwidth utilized by input devices and sensors on the input/sensor secondary display.

Techniques described herein also enable designation of different zones of a single integrated display surface, such as output primary zones and input primary zones. A state condition for a single display surface, for instance, can be used to infer a first portion of the display surface that is to be output primary and/or input primary, and a second portion of the display surface that is to be output secondary and/or input secondary.

In the following discussion, an example environment is first described that is operable to employ techniques described herein. Next, a section entitled "Example Implementation Scenarios" describes some example implementation scenarios in accordance with one or more implementations. Following this, a section entitled "Example Procedures" describes some example procedures in accordance with one or more implementations. Finally, a section entitled "Example System and Device" describes an example system and device that are operable to employ techniques discussed herein in accordance with one or more implementations.

Having presented an overview of example implementations in accordance with one or more implementations, consider now an example environment in which example implementations may by employed.

<FIG> is an illustration of an environment <NUM> in an example implementation that is operable to employ techniques for configuration of primary and secondary displays discussed herein. The environment <NUM> includes a client device <NUM> which can be configured in various ways. In at least one implementation, the client device <NUM> is configured for mobile use, such as a mobile phone, a tablet computer, a wearable device, a handheld gaming device, a media player, and so on. The client device <NUM> includes a display device <NUM> and a display device <NUM> that are connected to one another by a hinge <NUM>. Further, the display device <NUM> includes a touch surface <NUM>, and the display device <NUM> includes a touch surface <NUM>. The client device <NUM> also includes an input module <NUM> configured to process input received via one of the touch surfaces <NUM>, <NUM> and/or via the hinge <NUM>.

According to various implementations, the display devices <NUM>, <NUM> generally represent functionality for visual output for the client device <NUM>. Additionally, the display devices <NUM>, <NUM> represent functionality for receiving various types of input, such as touch input, stylus input, touchless proximity input, and so forth via one or more of the touch surfaces <NUM>, <NUM>, which can be used as visual output portions of the display devices <NUM>, <NUM>.

Generally, the hinge <NUM> is configured to rotationally move about a longitudinal axis <NUM> of the hinge <NUM> to allow an angle between the display devices <NUM>, <NUM> to change. In this way, the hinge <NUM> allows the display devices <NUM>, <NUM> to be connected to one another yet be oriented at different angles and/or planar orientations relative to each other. In at least some implementations, the touch surfaces <NUM>, <NUM> may represent different portions of a single integrated and continuous display surface that can be bent along the hinge <NUM>. Thus, the hinge <NUM> may represent a separate component that hingeably attaches the two separate touch surfaces <NUM>, <NUM>, or the hinge <NUM> may represent a portion of a single integrated display surface that includes the touch surfaces <NUM>, <NUM> and about which the touch surfaces <NUM>, <NUM> can bend.

While implementations presented herein are discussed in the context of a mobile device, it is to be appreciated that various other types and form factors of devices may be utilized in accordance with the claimed implementations. Thus, the client device <NUM> may range from full resource devices with substantial memory and processor resources, to a low-resource device with limited memory and/or processing resources. An example implementation of the client device <NUM> is discussed below with reference to <FIG>.

The client device <NUM> includes a variety of different functionalities that enable various activities and tasks to be performed. For instance, the client device <NUM> includes an operating system <NUM>, applications <NUM>, and a communication module <NUM>. Generally, the operating system <NUM> is representative of functionality for abstracting various system components of the client device <NUM>, such as hardware, kernel-level modules and services, and so forth. The operating system <NUM>, for instance, can abstract various components (e.g., hardware, software, and firmware) of the client device <NUM> to enable interaction between the components and applications running on the client device <NUM>.

The applications <NUM> are representative of functionality for performing different tasks via the client device <NUM>. Examples of the applications <NUM> include a word processing application, a spreadsheet application, a web browser, a gaming application, and so forth. The applications <NUM> may be installed locally on the client device <NUM> to be executed via a local runtime environment, and/or may represent portals to remote functionality, such as cloud-based services, web apps, and so forth. Thus, the applications <NUM> may take a variety of forms, such as locally-executed code, portals to remotely hosted services, and so forth.

The communication module <NUM> is representative of functionality for enabling the client device <NUM> to communicate over wired and/or wireless connections. For instance, the communication module <NUM> represents hardware and logic for communicating data via a variety of different wired and/or wireless technologies and protocols.

To enable various types of input to be received and utilized, the client device <NUM> includes input mechanisms <NUM>. Generally, the input mechanisms <NUM> represent different functionalities for receiving input to the client device <NUM>, and include a digitizer <NUM>, touch input devices <NUM>, touchless input devices <NUM>, and analog input devices <NUM>. Examples of the input mechanisms <NUM> include gesture-sensitive sensors and devices (e.g., such as touch-based sensors), a stylus, a touch pad, accelerometers, a microphone with accompanying voice recognition software, and so forth.

The digitizer <NUM> represents functionality for converting various types of input to the touch input devices <NUM>, the touchless input devices <NUM>, and the analog input devices <NUM> into digital data that can be used by the client device <NUM> in various ways. Generally, the touch input devices <NUM> represent functionality for receiving touch input to the client device <NUM>. Examples of the touch input devices include the display devices <NUM>, <NUM>, the hinge <NUM>, a touch pad, and so forth. The touch input devices <NUM>, for instance, may be separate or integral with the display devices <NUM>, <NUM>, with integral examples including gesture-sensitive displays with integrated touch-sensitive sensors. The touchless input devices <NUM> generally represent functionality for detecting input that does not involve physical contact with the client device <NUM>, such as a camera for detecting touchless gestures, proximity detection via capacitance sensing, and so forth.

The analog input devices <NUM> represent hardware mechanisms of the client device <NUM> that are usable to generate different physical quantities that represent data that can be interpreted as input to the client device <NUM>. Examples of input that can be detected via the analog input devices <NUM> include angle of the display devices <NUM>, <NUM> relative to one another, a position in which a user grips the client device <NUM>, a position of the client device <NUM> relative to gravity, and so forth. The client device <NUM>, for instance, includes sensors <NUM> that can be leveraged to implement the analog input devices <NUM>. Generally, the sensors <NUM> represent functionality for detecting different physical phenomena relative to the client device <NUM>.

The sensors <NUM>, for example, can include motion sensors and/or orientation sensors, such as accelerometers and/or gyroscopes configured to detect physical movement and orientation of the display devices <NUM>, <NUM> in space or relative movement and orientation with respect to a reference position. Further, the sensors <NUM> can include proximity sensors to detect a proximity of the user to one of the display devices <NUM>, <NUM>. The sensors <NUM> may also include audio sensors (e.g., a microphone and/or microphone array) to detect audio associated with an audio source (e.g., the user), such as voice commands issued by the user, and the audio can be used to determine a relative direction of the user with respect to the display devices <NUM>, <NUM> and which of the display devices <NUM>, <NUM> is substantially facing the user. Additionally, the sensors <NUM> can include grip sensors, such as touch sensors, configured to detect how a user is holding the client device <NUM>. Accordingly, a variety of different sensors <NUM> disposed on each of the display devices <NUM>, <NUM> and can be implemented to detect various different types of digital and/or analog input.

In at least one implementation, one or more sensors <NUM> can measure a hinge angle of the hinge <NUM>, and the one or more sensors <NUM> can provide the hinge angle as digital data usable by the client device <NUM> to perform various actions. For example, the sensors <NUM> can include one or more hinge sensors configured to detect a hinge angle between the display devices <NUM>, <NUM>. Thus, the hinge <NUM> can be leveraged as a mechanism to generate input data by measurement of a physical variable, such as hinge angle of the hinge <NUM>.

Further to techniques for configuration of primary and secondary displays described herein, the client device <NUM> includes and/or makes use of a state module <NUM>, which includes an inference module <NUM> and a verification module <NUM>. The state module <NUM>, for example, is included as part of an application or system software, such as the operating system <NUM>. Alternatively, the state module <NUM> represents a different standalone application or other functionality.

Generally, the state module <NUM> represents functionality for ascertaining, based on state conditions of the client device <NUM>, how to configure functionality of the display devices <NUM>, <NUM>. For instance, the state module <NUM> can utilize various types of state information to configure one or more of the display devices <NUM>, <NUM> as output primary or secondary, input primary or secondary, or sensor primary or secondary.

To assist the state module <NUM>, the inference module <NUM> represents functionality for inferring a user's intended primary and/or secondary display or input and/or output purposes. The inference module <NUM>, for instance, is configured to utilize input signals, such as those detected by the input mechanisms <NUM> and/or the sensors <NUM>, to determine a state of the client device <NUM> based on an orientation and a relative position of the client device <NUM> relative to the user, the ground, or another reference location, to make such an inference. Alternatively or additionally, the inference module <NUM> determine a state of the client device <NUM> based on functionality executing on the client device <NUM> (e.g., an application <NUM>), user interaction with and/or proximity to the client device <NUM>, and so forth.

The verification module <NUM> is representative of functionality to validate and/or verify decisions of the inference module <NUM> concerning a state of the client device <NUM>. In at least one implementation, the verification module <NUM> is configured to utilize various sensor signals from the sensors <NUM> to determine context information associated with the client device <NUM> in relation to the user and how the user is using the device. In addition, the verification module <NUM> can use the context information to verify a gesture being performed and/or to verify the inference made by the inference module <NUM>. By verifying the gesture being performed, the inference module <NUM> can avoid inadvertent or unintentional input being recognized as a gesture. In addition, by verifying whether the inference module <NUM> correctly determined which of the display devices <NUM>, <NUM> is to be used as output primary/secondary and/or input primary/secondary, inference errors can be identified and corrected. Thus, the user's experience can be improved over conventional techniques by automatically determining and configuring a display device as output primary/secondary, or input primary/secondary, without requiring the user to explicitly select the primary display. Further discussion of this and other features is provided below.

Having described an example environment in which the techniques described herein may operate, consider now a discussion of some example implementation scenarios in accordance with one or more implementations.

This section describes some example implementation scenarios for configuration of primary and secondary displays in accordance with one or more implementations. The implementation scenarios may be implemented in the environment <NUM> described above, the system <NUM> of <FIG>, and/or any other suitable environment. The implementation scenarios and procedures, for example, describe example operations of the client device <NUM>.

<FIG> illustrates an example implementation scenario <NUM> for using state information to determine a display device to be designated as output primary, input primary, and/or sensor primary. In the illustrated example, input data <NUM> and/or sensor data <NUM> is used to generate an input signal <NUM>. Generally, the input data <NUM> and/or the sensor data <NUM> represents data generated by the input mechanisms <NUM> and/or the sensors <NUM>. The input signal <NUM> can be detected from a variety of different types of input, such as a touch input (e.g., via a finger press or stylus input) to the touch surface <NUM> or the touch surface <NUM> of the client device <NUM>, a press of a hardware button, a bend in the hinge <NUM> of the client device <NUM>, a voice command via an audio sensor, or any combination of input mechanisms.

In implementations, the input signal <NUM> can include a user input <NUM>, a device gesture <NUM>, and/or an implicit gesture <NUM>. The user input <NUM> represents any suitable type of intentional input from a user, such as a touch input to the display device <NUM> and/or the display device <NUM>, voice input, and/or input via some other input mechanism <NUM> and/or sensor <NUM>. The device gesture <NUM> is recognized as a physical movement of at least one of the display devices <NUM>, <NUM> of the client device <NUM>. For instance, the physical movement leverages the hinge <NUM> such that a hinge angle between the display devices <NUM>, <NUM> is changed. The user, for example, may open the client device <NUM> from a closed posture, or further open the client device <NUM> from an open posture to a flipped posture where the display devices <NUM>, <NUM> face away from each other in opposite directions. Alternatively, if the client device <NUM> is in the flipped posture, the user may turn or flip the device over to see the opposite side, which includes a display device that was previously facing away from the user and is now facing toward the user. In at least one implementation, the device gesture <NUM> represents a type of the user input <NUM>.

The implicit gesture <NUM> may include physical movement of the client device <NUM> by the user where the user's intent is not to provide explicit input via the implicit gesture <NUM>, but rather the user is doing something naturally with the client device <NUM> that can be recognized and detected as a gesture from the system's point of view. For instance, the user may lift the client device <NUM> from a stationary location (e.g., on a table, or in a pocket), or turn the device to cause a display device to face away from the user and toward another person. From a system point of view, these actions can be considered to be gestures for input, even though the user may not explicitly intend them to be gestures.

Further to the scenario <NUM>, the inference module <NUM> is configured to use the input signal <NUM> to infer an output primary display and/or an input primary display. For instance, the inference module <NUM> is configured to determine which of the display devices <NUM>, <NUM> the user intends to be employed as an output primary display and/or an input primary display.

The input data <NUM> and/or the sensor data <NUM> may alternatively or additionally be leveraged to generate context information <NUM> to be used for interpreting the input signal <NUM>. For instance, the verification module <NUM> is configured to utilize the context information <NUM> to verify that the input signal <NUM> was actually an intentional input rather than an inadvertent or accidental input. Further, the verification module <NUM> is configured to use the context information <NUM> to refine the determination made by the inference module <NUM> as to which display devices <NUM>, <NUM> is to be a primary display for purpose of output and/or input. The context information <NUM> can be determined based on a variety of support signals that can be interpreted as context related to the client device <NUM> and/or a user of the client device <NUM>. This context information allows the system to better infer which display device the user intends to use as the primary screen.

The context information <NUM> can include a variety of different types and/or instances of data or signals, such as one or more of grip <NUM>, relative position <NUM>, application state <NUM>, behavioral data <NUM>, hall effect <NUM>, user settings <NUM>, calibration data <NUM>, visual data <NUM>, and external connections <NUM>. This is not an exhaustive list. Rather, these types of context information <NUM> are described as examples of the context information <NUM>, and are not to be construed as limiting. Further, the client device <NUM> can utilize some or all of the context information <NUM>, and can use any subset or combination of different types of the context information <NUM>.

The grip <NUM> indicates how the user is grasping or holding the client device <NUM> during and/or after the input signal <NUM>. For instance, the grip <NUM> can be detected by the sensors <NUM>, such as capacitive strips on the outside of the client device <NUM> or separate capacitive sensors on the rear exterior of the client device <NUM>. Alternatively or in addition, the grip <NUM> can be detected based on a capacitance of a display surface on the front of the client device <NUM>. The sensors <NUM> can detect whether the user has fingers wrapped around the client device <NUM>, which hand (e.g., left or right hand) the user is using to hold the client device <NUM>, in which of a variety of different device postures the user is holding the device, and so on. Accordingly, the grip <NUM> indicates how the user is holding the device, which is usable to infer how the user intends to use the device.

The relative position <NUM> refers to a relative position of the client device <NUM> in relation to the user of the client device <NUM>, in relation to the ground, and/or in relation to another reference location. For example, the relative position <NUM> can indicate whether the client device <NUM> is resting on a surface or whether a display device is facing the user. In implementations, the relative position <NUM> can be used to determine a current posture of the client device <NUM>. Various types of sensors <NUM> can be employed to determine the relative position <NUM>, including cameras, accelerometers, magnetometers, and so on.

The application state <NUM> represents identities and/or application types for one or more applications that are open on the client device <NUM>. The application state <NUM> may also be display specific, such as which application <NUM> is open on which particular display device <NUM>, <NUM>.

The behavioral data <NUM> is representative of how the user tends to interact with the client device <NUM> or particular applications executed on the client device <NUM>. For example, when using the client device <NUM> in a posture that allows the user to view both the display devices <NUM>, <NUM> simultaneously, the user may tend to run certain applications on the left side (e.g., display device <NUM>) and other applications on the right side (e.g., display device <NUM>). In another example, the user may generally take notes on the right side (e.g., display device <NUM>) of the client device <NUM> because the user is right-handed, and as a result, the user's hand does not obscure the other display device (e.g., display device <NUM>).

There are many different reasons why a user may have particular preferences related to how the user tends to use the client device <NUM>. The behavioral data <NUM>, although it may not explicitly represent preferences in the form of settings, includes behavioral information about how the user uses the device. Further, using the behavioral data <NUM>, some user actions can be anticipated. For example, when a notetaking application is launched, the system can use the behavioral data <NUM> to launch the notetaking application via a particular display device of the display devices <NUM>, <NUM> because the system knows the user has a preference for viewing the notetaking application via the particular display device and that the user likely intends that particular display device to be the input primary display.

The hall effect <NUM> refers to the production of a potential difference across an electrical conductor when a magnetic field is applied in a direction perpendicular to that of the flow of current. Hall effect sensors (e.g., magnetometer) can detect magnetic fields in close proximity. In implementations, the hall effect <NUM> can be used to detect when the client device <NUM> is opened from a closed posture to an open posture and to automatically turn on one or both of the display devices <NUM>, <NUM>. Alternatively or additionally, the hall effect <NUM> can be used to turn the display devices <NUM>, <NUM> off when the client device <NUM> is manipulated into the closed posture.

The user settings <NUM> can indicate how the user prefers to use the client device <NUM>, particularly with respect to ergonomics-related user settings that are set by the user or by default. Ergonomics-related user settings can be used to further refine the input signal <NUM> (e.g., left/right handedness can be used to predict a likely flip direction, or hand size information can be used for more reliable grip detection). By using information associated with the user settings <NUM>, the client device <NUM> can predict which direction the user is going to turn the device when the user's intent is to flip it over. This functionality can be useful in differentiating situations that are similar in nature, such as a first situation where the user rotates the device <NUM> degrees to see the reverse side, versus a second situation where the user rotates the device <NUM> degrees to show a friend content displayed via the primary display. In the first situation, the primary display can be changed to the reverse side to enable the user to view content via the reverse side. In the second situation, however, the user may not desire the primary display to change but may instead desire the primary display to temporarily face away from the user in order to show the displayed content to the friend, likely with the intent of then turning the device back around to continue viewing the original primary display. Accordingly, the user settings <NUM>, alone or in combination with other context information <NUM>, can be used to disambiguate similar situations.

The calibration data <NUM> describes information about the user, such as user properties that the system is aware of. For example, the calibration data <NUM> can include hand dimensions representing the size and shape of the user's hand(s) that is grasping the client device <NUM>. The hand dimensions can be used for more reliable grip detection. Further, the hand dimensions can be used to identify the user, the user's handedness (left or right), a shape of the user's fingers, and so on. This information can allow the system to more robustly detect how the user is holding the device, which can then be used to infer which display device is likely intended to be the output primary display and/or the input primary display based on the way the user would predictably perform the device gesture <NUM> or the implicit gesture <NUM>.

The visual data <NUM> refers to information captured via an image capturing device, such as a camera of the client device <NUM>. For example, the client device can include multiple integrated cameras. Each display device <NUM>, <NUM>, for instance, can be associated with one or more cameras, such as front-facing or rear-facing cameras. The cameras can capture images and/or video to detect whether a corresponding display device is facing the user. In implementations, the cameras can be used to detect whether the user is looking at a particular display device.

The external connections <NUM> refer to current connections between the client device <NUM> and one or more external devices. For example, the client device <NUM> can be connected to one or more external displays to display content, such as to give a presentation to a group of people. In this example, attention is given to the external device rather than the client device <NUM>. Thus, the external device is likely intended to be the output primary display, whereas one or more of the display devices <NUM>, <NUM> of the client device <NUM> are likely intended to be the input primary display.

Once the verification module <NUM> verifies the inferred primary display or corrects the inferred primary display, a display module <NUM> provides an output <NUM> for controlling the client device <NUM>. The output <NUM>, for example, indicates which of the display devices <NUM>, <NUM> is designated as an output primary display and/or an input primary display. The output <NUM> may also specify a particular action or set of actions to be performed relative to a primary display. For example, the display module <NUM> is configured to control power to each of the display devices <NUM>, <NUM>, and control which of the display devices <NUM>, <NUM> is to be used as the output primary display for output of content. In an example, the display module <NUM> is configured to cause an application to be displayed via a particular display device, change a power state of a display device (e.g., place a display device that is not intended to be used as the primary display into a low power state or "off" state, or turn on or wake a display device that is inferred to be the user's intended output primary display), and so on.

In an example implementation, one of the display devices <NUM>, <NUM> can be designated as a primary display for one purpose, and a secondary display for another purpose. For instance, based on the input signal <NUM> and the context information <NUM>, the output <NUM> can indicate that a particular display device is a primary display for purpose of receiving input to the client device <NUM>, but is a secondary display for purpose of displaying output from the client device <NUM>. Thus, the display device can be optimized for input and output characteristics of the display may be configured to deprioritize output. Further aspects for leveraging a division between primary and secondary purposes are detailed below.

In another example implementation, the sensors <NUM> can be controlled based on which display device <NUM>, <NUM> is designated as primary/input primary, and which display device <NUM>, <NUM> is designated as secondary/input secondary. For instance, in a display device that is designated as input primary, sensors <NUM> that are physically positioned within and/or adjacent the display device can be prioritized over other sensors <NUM> that are positioned within and/or adjacent a different display device that is designated as input secondary. Sensors <NUM> that that are positioned on a display device that is input secondary can be tuned down to reduce power consumption.

Further, in some implementations, different sensors <NUM> can be used in different implementations based on which gesture is detected, rather than using all the sensors <NUM> all the time. This can reduce power consumption and extend battery life. For instance, when the user flips the client device <NUM> over to view the reverse side, certain sensors (e.g., proximity sensors) can be considered for inferring the user's intended primary display. In contrast, when a different gesture is performed, such as a gesture that opens the client device <NUM>, the system can rely less on the proximity sensors and more on grip sensors. For instance, different sensor signals can be weighted differently based on different gestures. Accordingly, the client device <NUM> can determine, during performance of the gesture, which gesture is being performed and based on that determination, consider particular sensor signals to refine that determination (e.g., to verify that the determined gesture is in fact being performed). Conditionally considering signals from various sensors <NUM>, rather than simply using all the sensors <NUM> all the time, reduces required processing bandwidth and power consumption, which can lead to a longer battery life.

<FIG> depicts example implementation scenarios <NUM> for devices that are configurable for primary and secondary displays as described herein. The scenarios <NUM> include various different configurations of devices having multiple touch surfaces. The devices discussed in the scenarios <NUM>, for instance, represent different instances of the client device <NUM>.

For example, in scenario 300a, the display devices <NUM>, <NUM> are physically connected to one another via the hinge <NUM> and include the touch surfaces <NUM>, <NUM>, respectively. The hinge <NUM> may be implemented in various ways, such as a pivot, a joint, a swivel, and flexible display region, and so on. Generally, the hinge <NUM> enables the display devices <NUM>, <NUM> to be positioned in a variety of different postures, such as a "closed book" posture where the touch surfaces <NUM>, <NUM> face each other. Additionally, the display devices <NUM>, <NUM> can be positioned in an "open book" posture as shown in the configuration <NUM>. In the configuration <NUM>, the touch surfaces <NUM>, <NUM> are positioned relative to one another such that a user can view content presented on both touch surfaces <NUM>, <NUM>, such as at an angle between <NUM> degrees and <NUM> degrees. In yet another example position, the touch surfaces <NUM>, <NUM> can be parallel with one another in a side-by-side configuration where both touch surfaces <NUM>, <NUM> face the same direction, such as shown below in the scenario 300c. In at least one implementation, the display devices <NUM>, <NUM> can be positioned such that the touch surfaces <NUM>, <NUM> face substantially opposite directions, as illustrated in example configuration <NUM>. According to various implementations, a relative orientation of the touch surfaces <NUM>, <NUM> can be interpreted to designate a particular touch surface as being either input primary or output primary. Further, the relative orientation can be used to configure sensors <NUM> for the display devices <NUM>, <NUM>.

<FIG> further depicts a scenario 300b, which includes a bendable device <NUM> having a display device <NUM> that is bendable about a flexible region <NUM> into different configurations, causing at least a portion of the display device <NUM> to be hidden from the user's view. For example, the bendable device <NUM> can be shaped into a position having a first portion 310a of the display device <NUM> facing the user and a second portion 310b of the display device <NUM> that is non-planar with the first portion 310a, such that the second portion 310b of the display device <NUM> is essentially "on the backside" of the bendable device <NUM>. Accordingly, a variety of different positions and configurations of the bendable device <NUM>. Accordingly, a variety of different positions and configurations of the bendable device <NUM> are contemplated, and are not necessarily limited to a front/back configuration.

In at least one implementation, a relative orientation of the first portion 310a and the second portion 310b can determine which portion is input primary, and which portion is output primary. For instance, consider that a user <NUM> is wearing the bendable device <NUM> on the user's wrist, such as a smartwatch or other wearable smart appliance. The first portion <NUM>10a of the display device <NUM> is positioned such that the user <NUM> can view the first portion 310a, but the second portion 310b is positioned away from the user's viewable area such that the user <NUM> cannot see the second portion 310b. In this scenario, the first portion 310a may be configured to be input primary and output primary since the user <NUM> is likely to view and interact with the first portion 310a. Thus, input functionality and/or output functionality of the second portion 310b may be operated under reduced power since the user <NUM> is unlikely to view or interact with the second portion 310b of the display device <NUM>.

In another implementation, the first portion 310a may be designated as output primary since the first portion 310a is in a position to be viewable by the user <NUM>, whereas the second portion 310b may be designed as input primary to enable the user <NUM> to provide touch input to the second portion 310b. For instance, the user <NUM> can provide touch input to the second portion 310b via the user's finger <NUM>, such as tap input, sliding gesture input, and so forth. In one example, the user <NUM> can slide the finger <NUM> across the second portion 310b of the display device <NUM> to cause a corresponding movement of a cursor <NUM> across the first portion 310a of the display device <NUM>. The user <NUM> may also tap the finger <NUM> on the second portion 310b to cause a selection action to occur to select content over which the cursor <NUM> is positioned.

<FIG> also depicts a scenario 300c, which includes a device <NUM> with a single integrated display <NUM> that can be bent along the hinge <NUM>. The single integrated display <NUM> can include multiple display portions, such as display portion <NUM> and display portion <NUM>, each of which can include touch screen functionality. The display portions <NUM>, <NUM> can be used to display different content, such as different application user interfaces, or the display portions <NUM>, <NUM> can be used to display content via a single application user interface across both of the display portions <NUM>, <NUM>. In an example, display portion <NUM> can be designated as the primary display for presentation of an interactive application (e.g., notetaking application) while the other display portion <NUM> can be used to display a comparatively-less interactive application, such as a media player application. In another example, both display portions <NUM>, <NUM> can be designated as the primary display, such as for playback of video content across both of the display portions <NUM>, <NUM>. Alternatively, a single application user interface displayed across both of the display portions <NUM>, <NUM> can present user interface controls via a designated primary display, which may correspond to the user's handedness, e.g., right/left hand.

<FIG> illustrates example implementation scenarios <NUM> for postures of a hinged device in accordance with one or more implementations. The scenarios <NUM> each include an instance of the client device <NUM> from <FIG> positioned in a different particular posture (e.g., position and orientation in space). For example, a scenario 400a represents a "laptop" posture in which the display device <NUM> is resting on a surface and facing a direction opposite the surface. For instance, the client device <NUM> may be resting on a table, a desk, a user's lap, or any other suitable surface. Further, the display device <NUM> is facing toward the user <NUM>. In the scenario 400a, a hinge angle <NUM> is formed between the display device <NUM> and the display device <NUM>, such as between <NUM> and <NUM> degrees.

Further to the scenario 400a, the state module <NUM> can determine, based on various criteria, which of the display devices <NUM>, <NUM> is to be input primary, and which is to be output primary. For instance, the state module <NUM> can determine that based on the display device <NUM> being positioned on a surface and the display device <NUM> being positioned at a viewing angle, the display device <NUM> is to be output primary, and the display device <NUM> is to be input primary. Thus, the display device <NUM> can be optimized for output, such as by increasing a display resolution and/or display brightness in comparison to the display device <NUM>. Alternatively or additionally, a display resolution and/or brightness of the display device <NUM> can be reduced relative to the display device <NUM>.

For example, consider that the touch surface <NUM> of the display device <NUM> is utilized as an input surface, such as for receiving touch input. A virtual keyboard, for instance, can be displayed on the touch surface <NUM> to enable a user to enter text and other characters for display on the display device <NUM>. Alternatively or additionally, the touch surface <NUM> can receive touch gestures to manipulate visual objects displayed on the display device <NUM>. Accordingly, display characteristics of the display device <NUM> (e.g., resolution, brightness, and so forth) can be turned down since output performance is not a high priority in an input primary scenario. In one example, visual output of the display device <NUM> may be turned off in the scenario 400a since the display device <NUM> is designated as output primary. Even though visual output of the display device <NUM> may be turned off, the touch surface <NUM> may remain active to receive touch input, such as to enable the touch surface <NUM> to act as a touchpad for manipulating (e.g., moving and/or selecting) objects displayed on the display device <NUM>.

As part of differentiating between input and output primary, different sensors <NUM> positioned on the display device <NUM> and the display device <NUM> may be operationally configured in different ways. For instance, sensors 134a positioned on the display device <NUM> (e.g., the touch surface <NUM>) can be optimized for input, such as by turning up sensor sensitivity, sensor polling rate, and so forth. Further, since input to the touch surface <NUM> of the display device <NUM> is less likely as compared to the touch surface <NUM>, sensors 134b positioned on the display device <NUM> can be turned down. For instance, sensor sensitivity and/or polling rate for the sensors 134b on the display device <NUM> can be turned down.

A scenario 400b represents the client device <NUM> in a "book" posture, in which the client device <NUM> is held similar to a paper book. The state module <NUM>, for instance, detects that the client device <NUM> is in the book posture, such as based on the sensors <NUM> detecting an angle between the display devices <NUM>, <NUM> and an orientation of the display devices <NUM>, <NUM> relative to gravity. Alternatively or additionally, the state module <NUM> can detect that the user <NUM> is holding the client device <NUM> in the depicted orientation, such as in a book grip posture. Here, one or both of the display devices <NUM>, <NUM> can be designated as output primary. Further, one or both of the display devices <NUM>, <NUM> can be designated as input secondary.

<FIG> further depicts a scenario 400c in which the client device <NUM> in a "flipped" posture in which the display devices <NUM>, <NUM> are facing opposite directions. The hinge <NUM>, for instance, has been bent to "flip" the display device <NUM> around behind the display device <NUM>. In this scenario 400c, the display device <NUM> is viewable by the user <NUM>, but the display device <NUM> is not viewable by the user because the display device <NUM> faces away from the user. The state module <NUM>, for instance, detects via a sensor 134c that the user's face is detectable as in a viewing position of the display device <NUM>, but is not detectable in a viewing position of the display device <NUM>.

Accordingly, the display device <NUM> is designated as output primary and input primary. In at least one implementation, the display device <NUM> is designated as output secondary and input secondary. The display device <NUM>, for instance, may be placed in a low power state or turned off. The touch surface <NUM>, however, may remain active such that the user <NUM> can provide touch input to the touch surface <NUM> while viewing output from the display device <NUM>.

In at least one implementation, optical sensors <NUM> of the display device <NUM> can be optimized to receive visual input, such as by turning up sensor sensitivity and/or polling rate. Examples of visual sensors include a camera, a photoelectric sensor, a laser, and so forth. Further, since the display device <NUM> is positioned out of view of the user <NUM>, optical sensors <NUM> of the display device <NUM> can be turned down and/or turned off.

A scenario 400d represents a "tent" posture in which the client device <NUM> is placed in a landscape orientation with the display devices <NUM>, <NUM> facing outward. An outer edge <NUM> of the display device <NUM> and an outer edge <NUM> of the display device <NUM>, for instance, are placed on an adjacent surface such as a desk or a table. Here, the client device <NUM> is positioned to allow each of the display devices <NUM>, <NUM> to be viewed by different users. For example, the user <NUM> may view the display device <NUM> and a different user <NUM> (e.g., sitting across from the user <NUM>) may view the display device <NUM>. Accordingly, the tent posture can allow different experiences to be presented on the display devices <NUM>, <NUM>, respectively.

In at least one implementation, one of the display devices <NUM>, <NUM> can be designated as input primary and another of the display devices <NUM>, <NUM> can be designated as output primary. For instance, differentiation between input primary and output primary for the display devices <NUM>, <NUM> can be based on differing roles for the users <NUM>, <NUM>. Consider, for instance, that the state module <NUM> detects that the user <NUM> is in a viewing position for the display device <NUM>, such as using face detection or other user identification technique. Further, the user <NUM> is identified as a primary user of the client device <NUM>, such as based on a user profile for the user <NUM>. Accordingly, the state module <NUM> can designate the display device <NUM> as input and output primary, but can designate the display device <NUM> as output primary and input secondary. This supports a scenario where the user <NUM> can provide input to the touch surface <NUM> to select and manipulate content for display on the display device <NUM>. In one implementation, the display device <NUM> can be designated as output secondary and the display device <NUM> designated as output primary, such as to prioritize visual output to the user <NUM> for content selected and/or generated by the user <NUM> via interaction with the touch surface <NUM>.

<FIG> depicts an example implementation scenario <NUM> for configuration of primary and secondary displays in accordance with one or more implementations. In the scenario <NUM>, the client device <NUM> is positioned with the display devices <NUM>, <NUM> side by side such that the touch surfaces <NUM>, <NUM> together form an approximately planar surface. A hinge angle of the hinge <NUM>, for instance, is approximately <NUM> degrees, +/- <NUM> degrees.

The upper portion of the scenario <NUM> depicts the display devices <NUM>, <NUM> displaying content <NUM> via both of the display devices <NUM>, <NUM>. The display devices <NUM>, <NUM>, for instance, are both designated as output primary displays and input secondary displays. Generally, this can occur when a user selects to view content across both of the display devices <NUM>, <NUM>. The user, for instance, initiates a full screen viewing of the content <NUM> across the display devices <NUM>, <NUM>. The content <NUM> can represent various types of visual content, such as a still image, video, animation, and so forth.

Proceeding to the lower portion of the scenario <NUM> and without changing a posture of the client device <NUM> (e.g., the orientation of the display devices <NUM>, <NUM> relative to one another), the user launches a notetaking application 120a on the client device <NUM>. Generally, the notetaking application 120a can be launched in various ways. The user, for instance, brings a pen <NUM> in proximity to and/or in contact with the touch surface <NUM>, and the operating system <NUM> interprets this as a request to launch the notetaking application 120a. Based on a sensor signal and/or context information, the state module <NUM> can infer that the display device <NUM> is intended by the user to be used as a primary input surface for the notetaking application 120a. For example, the pen <NUM> in proximity to the touch surface <NUM> is interpreted as an intent to use the display device <NUM> as an input primary display device. Alternatively or additionally, the application 120a can be identified as being an input primary and/or output secondary application.

As another example, by detecting the user's left hand <NUM> grasping the client device <NUM>, the system can identify the user, based on hand size and/or shape, and can determine that the user is right handed based on known attributes of the user obtained via the user settings <NUM>, the behavioral data <NUM>, or both. Alternatively or in addition, because the user is grasping the client device <NUM> with the left hand <NUM>, the system can infer that the user is intending to write notes with a right hand <NUM> because generally users do not grasp the client device <NUM> with a dominant writing hand. In addition to knowing that the user is right handed, the system can use the behavioral data to determine that the user has a history of using the notetaking application 120a and/or similar types of applications (e.g., based on classification, user interface controls, functionalities, and/or content of the applications) via display device <NUM>. This may be because the user can write with the right hand without obscuring the display device <NUM>.

Accordingly, the client device <NUM> can utilize information for the sensors <NUM> and/or context information <NUM> to infer that the input primary display is the display device <NUM>, and the output primary display is the display <NUM>. Using this information, the client device <NUM> can then move and resize the display of the content <NUM> to display the content <NUM> only via the display device <NUM>, and launch the notetaking application 120a via the inferred input primary display, e.g., the display device <NUM>.

In at least one implementation, the display device <NUM> is designated as both output primary and input secondary. For instance, since the user is providing input to the display device <NUM> and gripping the client device <NUM> via the display device <NUM>, the state module <NUM> can infer that the user is less likely to provide input to the display device <NUM>. Accordingly, the state module <NUM> can configure the display device <NUM> as input secondary, attributes of which are discussed throughout this disclosure. Further, the display device <NUM> can be designated as both input primary and output secondary. Since the user is writing notes on the display device <NUM> (e.g., via digital ink), output properties of the display device <NUM> (e.g., resolution, brightness, and so forth) may be considered less important, and thus these properties can be turned down to conserve battery life.

Further, and as a consequence of the differentiation between different usage scenarios of the display devices <NUM>, <NUM>, sensors on the respective display devices <NUM>, <NUM> can be configured in different ways. For instance, the display device <NUM> can be designated as sensor primary to enable different user interactions with the display device <NUM> to be more accurately captured and interpreted. Further, the display device <NUM> can be designated as sensor secondary since the user is viewing the content <NUM> displayed on the display device <NUM> and is less likely to provide input to the display device <NUM> than to the display device <NUM>. Different configuration attributes of sensor primary and sensor secondary display devices are discussed throughout this disclosure.

Accordingly, any of a variety of different postures can be utilized to configure connected display devices as either output primary or output secondary, and/or input primary or input secondary. Further, a change from one posture to another posture can trigger a change in designation as output primary and/or input primary. For example, a change in the hinge angle of the hinge <NUM> between the display devices <NUM>, <NUM> can trigger a change in the primary display if the change in the hinge angle is greater than a threshold value, e.g., <NUM> degrees, <NUM> degrees, <NUM> degrees, and so on. Any suitable threshold value can be utilized for the change in the hinge angle to trigger a change in an input primary and/or output primary display. In implementations, a physical displacement, rather than a hinge angle change, can trigger a change in the primary display. For example, with reference to <FIG>, the physical displacement can include a posture change from the laptop posture in scenario 400a to the book posture in the scenario 400b, where the hinge angle remains substantially the same but the orientation of the client device <NUM> is rotated from a landscape orientation to a portrait orientation. Techniques described herein, for example, can infer a user's intended primary output display and/or input display based on physical movement (e.g., physical displacement, change in the hinge angle) of the client device <NUM> in order to automatically present the content to the user in the manner desired by the user.

As an alternative or addition to the above considerations, a change in how a user grips the client device <NUM> can be used to assign or reassign a display device as output primary and/or input primary. For instance, with reference to the scenario <NUM>, consider that the user changes from gripping the client device <NUM> as depicted in the lower portion of the scenario <NUM> (i.e., via a side of the client device <NUM>), to resting the client device <NUM> in a palm of the user's hand as depicted in the upper portion of the scenario <NUM>. Generally, this mimics a user holding a book in their hand. Accordingly, the state module <NUM> can detect this change in device grip posture, and can cause a change in output primary and/or input primary designation for the display devices <NUM>, <NUM>. For instance, based on the change in grip position, the state module <NUM> can infer that the user intends to view the content <NUM> across both of the display devices <NUM>, <NUM>. Accordingly, both of the display devices <NUM>, <NUM> can be designated as output primary displays. Further, the content <NUM> that was displayed only on the display device <NUM> (such as in the lower portion of the scenario <NUM>) can be resized and repositioned to be displayed across both of the display devices <NUM>, <NUM>, such as depicted in the upper portion of the scenario <NUM>.

In at least one implementation, an indication of which display is to be designated as output primary and/or input primary can be provided to the user. For instance, in the scenario <NUM> and in response to switching the display device <NUM> to output primary and the display device <NUM> to input primary, an output primary notification <NUM> is presented in the display device <NUM>, and an input primary notification <NUM> is presented on the display device <NUM>. Generally, the output primary notification <NUM> represents a visual notification that the display device <NUM> is switching to output primary. Further, the input primary notification represents a visual notification that the display device <NUM> is switching to input primary. In this way, the user can be informed of which display device will be configured as output primary, and which display device will be configured as input primary.

According to one or more implementations, a user-selectable option to override the determination of which display device is to be the input primary and/or output primary is provided. The user, for instance, can select the output primary notification <NUM> to prevent switching the display device <NUM> to an output primary mode. Further, selecting the input primary notification <NUM> can prevent switching the display device <NUM> to an input primary mode. In one example implementation, selecting either the output primary notification <NUM> or the input primary notification <NUM> causes both of the display devices <NUM>, <NUM> to operate in a standard input/output mode such that neither display device is configured as output primary or input primary.

Techniques described herein can be leveraged to interpret user actions overriding decisions concerning output primary and input primary displays to inform future decisions whether to switch a display device to output primary and/or input primary. For instance, based on an explicit override input by the user (e.g., via selection of the output primary notification <NUM> and/or the input primary notification <NUM>), the verification module <NUM> can update weightings used by the inference module <NUM> to improve future decisions whether to switch a display device to input primary and/or output primary.

While implementations are discussed herein within the context of a multi-screen device, it is to be appreciated that techniques for configuration of primary and secondary displays may be employed in the context of a single screen device. Consider, for example, the following scenario.

<FIG> depicts an implementation scenario <NUM> in which different zones of a display device can be configured in different ways. The scenario <NUM> includes an instance of the client device <NUM> including a display device <NUM> with a display surface <NUM>. In at least one implementation, this instance of the client device <NUM> represents an interactive device such as a meeting room device configured to enable users to view and interact with the client device <NUM> as part of an interactive session, such as a multi-person meeting. The display <NUM>, for instance, is a large-screen display and the display surface <NUM> supports touch input to manipulate content displayed on the display surface <NUM>.

According to various implementations, the display surface <NUM> is divided into different zones that are independently controllable to adjust output properties and input properties of the zones. In this particular example, the display surface <NUM> includes a zone 606a, a zone 606b, a zone 606c, and a zone 606d. This particular arrangement of zones is presented for purpose of example only, and another instance of the display device <NUM> can include any shape, size, and/or arrangement of zones within the scope of the claimed implementations. Further, the dashed lines are included for purposes of this discussion to generally represent a separation between zones, and are not intended to represent elements that are visible in a typical usage of the client device <NUM>.

Generally, each of the zones 606a-606d is independently controllable to enable each zone to be designated as input primary and/or output primary. For instance, based on a particular detected condition, one of the zones 606a-606d can be designated as input primary, and another of the zones 606a-606d can be designated as output primary.

In one example, user proximity and/or interaction with the display surface <NUM> causes a configuration of one or more of the zones 606a-606d as input primary and/or output primary. For instance, and proceeding to the lower portion of the scenario <NUM>, consider that a user <NUM> approaches the display device <NUM>. The client device <NUM> detects the proximity and position of the user <NUM>. In this particular example, the client device <NUM> includes a position sensing device <NUM>, e.g., a camera. Alternatively or additionally, proximity and position of the user <NUM> can be detected in other ways, such as based on user contact with the display surface <NUM>. Generally, the position sensing device <NUM> can detect a proximity and position of the user <NUM> relative to the display surface <NUM>.

Further to the scenario <NUM>, the state module <NUM> ascertains (e.g., leveraging the position sensing device <NUM>) that the user <NUM> is positioned in front of the zones 606a, 606c and is thus closer in proximity to the zones 606a, 606c than to the zones 606b, 606d. Accordingly, the state module <NUM> designates the zones 606b, 606d as output primary, and the zones 606a, 606c as output secondary. For instance, since content displayed within the zones 606a, 606c is likely at least partially obscured by the user <NUM>, the state module <NUM> can infer that content displayed within the zones 606b, 606d is likely higher priority content for output. Thus the zones 606b, 606d can be configured (e.g., optimized) for visual output. Different ways of configuring a display and/or portions of a display as output primary are discussed throughout, and include operations such as maintaining, for the output primary zones, a higher display brightness and/or resolution than for other non-output primary zones.

In at least one implementation, the zones 606b, 606d can also be designated as input primary since the user <NUM> is more likely to interact with content presented within the zones 606b, 606d. The zones 606a, 606c may also be designated as input secondary since the user <NUM> is less likely to interact with these zones based on the current location of the user.

According to techniques for configuration of primary and secondary displays described herein, designation of input/output primary portions of the display surface <NUM> can change dynamically, such as based on a change in the user <NUM>'s position. For instance, consider that the user <NUM> wishes to interact with content displayed in the zones 606a, 606c, and to enable other users to view this content. Accordingly, the user moves to the right in front of the zones 606b, 606d. Accordingly, the state module <NUM> detects the change in position, such as via position data received from the position sensing device <NUM>. Since the user <NUM> is now positioned in front of the zones 606b, 606d, the zones 606a, 606c are reconfigured as output primary and input primary. Further, the zones 606b, 606d are reconfigured as output secondary and input secondary. Thus, techniques described herein can dynamically adapt to various state changes for controlling input and output mode designations.

Having described some example implementation scenarios, consider now some example procedures for configuration of primary and secondary displays in accordance with one or more implementations.

The following discussion describes example procedures for configuration of primary and secondary displays in accordance with one or more implementations. The example procedures may be employed in the environment <NUM> of <FIG>, the system <NUM> of <FIG>, and/or any other suitable environment. The procedures, for instance, represent procedures for implementing the example implementation scenarios discussed above. In at least some implementations, the steps described for the various procedures can be implemented automatically and independent of user interaction, such as by the state module <NUM>. Further, the steps described in the procedures below can be performed in any suitable combination and/or order, and are not intended to be construed as limited to the orders described.

<FIG> is a flow diagram that describes steps in a method in accordance with one or more implementations. The method, for instance, describes an example procedure for configuring a display device based on a likely intended usage of the display device.

Step <NUM> determines a likely intended usage of a first display device of an apparatus relative to a second display device of the apparatus based on a state condition of the apparatus. Examples of different state conditions are discussed above, and include:.

Display device angle - an angle of the first display device relative to the second display device. This angle can be determined in various ways, such as based on relative angle between respective display surfaces of the respective display devices, rotation angle of a hinge that connects the display devices, comparative angles of the display devices relative to a gravitational vector, and so forth.

Application state - an identity and/or type of application that is launched on the apparatus, such as on a particular display device. The application, for instance, may be characterized as being input primary or output primary, such as based on an experience provided by the application. For example, a video player application can be characterized as output primary since its primary function is to output content. A notetaking application, however, can be characterized as input primary, since its primary function is to receive user input of notes and other annotations.

Grip posture - a way in which is a user is gripping the apparatus. A grip, for instance, represents a user grasping the apparatus at a particular region, and/or resting the apparatus in the user's hand. Generally, certain grips such as grasping the apparatus on both sides using two hands can be designated as output primary. Other grips, such as grasping the apparatus only on one side can be designated as input primary.

User profile - a behavior profile for a user that is interacting with the apparatus. The profile, for instance, can indicate past user behavior in certain contexts, such as whether a user interacts with a particular experience primarily for output or primarily for input. For example, consider a scenario where two applications are open, a first application on the first display device and a second application on the second display device. If a user typically provides less input (e.g., no input) to the first application than to the second application, then the first display device can be designated as output primary, and the second display device as input primary.

As another example, known physical and behavioral traits of a user can be used to infer output primary and input primary displays. For instance, if a user is known to be left handed, then a display device oriented on the left side of an apparatus can be designated as input primary, and a display device oriented to the right as output primary.

In a further example, a user can expressly identify which display device is to be output primary, and which display device is to be input primary. In this case, a device state context in which the user selects the output primary and input primary displays can be saved and used as part of a subsequent decision regarding output and input primary displays. Different examples of device state are discussed above, such as applications that are open on different display devices.

Other examples of state conditions are contemplated, such as discussed above with reference to the context information <NUM>. Accordingly, any one or combination of the different state conditions described herein can be employed to determine which display to designate as output primary, and which display to designate as input primary.

Step <NUM> ascertains based on the likely intended usage that the first display device is likely intended to be used as a primary output device. The determined likely intended usage, for instance, indicates that a user is likely to utilize the first display predominantly for output purposes. Alternatively or additionally, the likely intended usage indicates that the user is likely to utilize the second display device predominantly for input purposes.

Step <NUM> configures output functionality of the first display device as output primary and input functionality of the first display device as input secondary. Configuring output functionality of a display device as output primary can include one or more of a number of different output device configurations, such as:.

Display resolution - display resolution of an output primary display device can be maintained at a higher resolution than another display that is not an output primary display.

Display Brightness - brightness of an output primary display device can be maintained at a higher brightness value than another display that is not an output primary display.

Refresh Rate - a refresh rate of an output primary display can be configured to be higher than a non-output primary display.

Color Gamut - an available color gamut for an output primary display can include a greater number of color options than an available color gamut for a non-output primary display.

These example configurations for an output primary display are presented for purpose of example only, and it is to be appreciated that an output primary display can be configured in a variety of different ways not expressly mentioned herein.

Configuring input functionality of a display device as input secondary can include one or more of a number of different input device configurations and at least one of the first two input device configurations:.

Input device sensitivity - touch sensitivity of an input secondary device can be maintained at a lower level than an input primary device. For instance, voltage level of a touch sensitive input device (e.g., a capacitive sensor) can be decreased as compared to an input primary device.

Input device sampling rate - a touch sampling rate for an input secondary device can be maintained at a lower rate than an input primary device.

Input device availability - in a scenario where an input secondary device includes multiple different input devices, one or more input devices can be deactivated. For instance, consider that an input secondary device includes multiple touch-sensitive input devices, such as a grip sensor in a bezel, and a separate touchscreen. The grip sensor can be turned down and/or deactivated in the input secondary mode.

These examples of input secondary configurations are presented for purposes of example only, and it is to be appreciated that configuring a display device as input secondary generally causes power allocated to the display device to be reduced as compared to an input primary device.

According to one or more implementations, configuring display devices as either sensor primary or sensor secondary can be performed concurrently, in parallel with, or alternatively to configuring display devices as input/output primary, or input/output secondary. For instance, the following steps depicted in <FIG> can be performed concurrently, in parallel with, or alternatively to the steps described above.

Step <NUM> ascertains based on the state condition that the first display device is to be configured as a sensor primary device. Examples of different state conditions are discussed above. For instance, a state condition that is considered to determine whether a display device is to be output primary or output secondary may additionally or alternatively be considered to determine whether the display device is to be sensor primary or sensor secondary.

In one or more implementations, designating a display device as sensor primary or sensor secondary may be based on whether the display device is designated as output primary or input primary. With reference to the client device <NUM>, for example, when the display device <NUM> is designated as output primary, the display device <NUM> is designated as sensor primary. This contemplates a scenario where the user is viewing content via the display device <NUM>, and is interacting with (e.g., providing input to) the display device <NUM> such that greater sensor sensitivity is provided to the display device <NUM> than to the display device <NUM>. In an alternative implementation, a display device that is designated as output primary can also be designated as sensor primary. For instance, when an output primary device is leveraged to display interactive content configured to receive user input, the output primary device may also be designated as sensor primary to provide fast and accurate interpretation and response to user input to the output primary device.

Step <NUM> configures sensor functionality of the first display device as sensor primary and sensor functionality of the second display device as sensor secondary.

Configuring sensor functionality of a display device as sensor primary or sensor secondary can include one or more of a number of different sensor configurations, such as:.

Sensor sensitivity - sensitivity of a sensor on a sensor primary device can be maintained at a higher level than a sensor on a sensor secondary device. For instance, voltage level of a touch sensitive input device (e.g., a capacitive sensor) can be maintained at a higher level as compared to a sensor secondary device.

Sensor sampling rate - a sensor sampling rate for sensor primary device can be maintained at a higher rate than a sensor secondary device.

Sensor batching - sensor data from a sensor secondary device can be batched over a period of time instead of providing the sensor data at smaller time intervals. For instance, sensor data from a sensor of a sensor secondary device can be batched between sampling periods and provided in response to a request for sensor data from the sensor.

Sensor availability - in a scenario where a sensor secondary device includes multiple different sensors, one or more input devices can be deactivated. For instance, consider that a sensor secondary device includes multiple light sensors, such as a camera and a separate photoelectric sensor. The camera can be turned down and/or deactivated in the sensor secondary mode, such as to preserve battery life.

These examples of sensor primary/secondary configurations are presented for purposes of example only, and it is to be appreciated that configuring a display device as sensor secondary generally causes power allocated to sensor functionality of the display device to be reduced as compared to a sensor primary device.

<FIG> is a flow diagram that describes steps in a method in accordance with one or more implementations. The method, for instance, describes an example procedure for returning sensor data based on a primary sensor configuration.

Step <NUM> receives a query for a particular type of sensor data. The operating system <NUM>, for instance, receives a request from an application <NUM> for a particular type of sensor data. Examples of different types of sensor data include touch sensor data, light sensor data (e.g., from a photodetector), image and/or video data (e.g., from a camera), sound sensor data, grip sensor data (which may be a type of touch data), and so forth. In at least one implementation, the request identifies the particular type of sensor data without identifying a specific sensor or sensor type to be used to retrieve the sensor data. For example, the request may request an "image capture" from the client device <NUM> without identifying an instance of a sensor to be used to capture the image, or identifying a sensor type (e.g., "camera") to be used to capture the image. Alternatively, the request may request that a discrete instance of a sensor be used to capture the sensor data, and/or a specific type of sensor to be used to capture the sensor data.

Step <NUM> identifies a primary sensor that is available to capture the particular type of sensor data. The operating system <NUM>, for instance, identifies which sensor is identified as being a primary sensor for providing the particular type of sensor data. In at least one implementation, a sensor that resides on a sensor primary display device and that is capable of providing the particular type of sensor data is designated as a primary sensor for the particular type of sensor data. The state module <NUM> may track which sensors <NUM> are primary sensors for different particular types of sensor data, and may provide this information to a requesting entity such as the operating system <NUM> and/or an application <NUM>. Generally, multiple different sensors may reside on the client device <NUM> that are configured to provide the particular type of sensor data, and a primary sensor may be designated from among these different sensors based on different criteria, such as based on the sensor residing on a sensor primary display device.

Step <NUM> obtains sensor data of the particular type of sensor data from the primary sensor. For instance, the operating system <NUM> interfaces with the primary sensor to obtain sensor data of the particular type. This may be performed in various ways, such as by interfacing directly with primary sensor hardware, and/or interfacing with a sensor driver or other sensor management functionality.

Step <NUM> communicates a query response that includes the sensor data. The operating system <NUM>, for example, communicates the sensor data to a requesting entity, such as an application <NUM>. In at least one implementation, the sensor data does not identify a specific sensor from which the sensor data was obtained, e.g., the primary sensor for the requested type of sensor data.

Additionally or alternatively to communicating a query response including the sensor data, the primary sensor may be identified to the requesting entity to enable the entity to obtain sensor data directly from the primary sensor. For instance, the operating system <NUM> can identify the primary sensor to a requesting application <NUM>, and the application <NUM> can obtain the sensor data directly from the primary sensor.

As mentioned above, in at least one scenario a request for sensor data may identify a particular sensor and/or sensor type to be used to obtain the sensor data. If the sensor/sensor type identified in the request is different than the identified primary sensor, the primary sensor may be used to obtain the sensor data thus overriding the requested sensor/sensor type. This enables the system to adapt to dynamic changes in sensor configuration and thus provide more reliable sensor data, such as when a requested sensor/sensor type is unavailable or is functionally impaired by a current device state.

While the procedures described above are discussed with reference to multi-display device scenarios, implementations for configuration of primary and secondary displays described herein may also be employed to configure operation of a single screen. Consider, for instance, the following example procedure.

<FIG> is a flow diagram that describes steps in a method in accordance with one or more implementations. The method, for instance, describes an example procedure for configuring different zones of a display device.

Step <NUM> determines a state condition for a display device having multiple independently configurable zones, the state condition indicating that a first zone of the display device is likely to be used as a primary output portion of the display device. Examples of different state conditions that can be used to designate an output primary display and/or portion of a display are discussed above, such as user proximity to a different portion of the display, a particular application displayed on the first zone, user input to identify the first zone as output primary, and so forth.

Step <NUM> configures the first zone of the display surface as output primary based on the state condition. Different ways of configuring a display and/or portions of a display for output primary are discussed above, such as maintaining a higher display resolution and/or brightness for the output primary zone(s) than for non-output primary zone(s). In at least one implementation, the first zone can also be configured as input primary.

Step <NUM> configures a second zone of the display surface as output secondary based on the state condition. Display characteristics of the second zone, for instance, are configured to deemphasize output at the second zone. Different ways of configuring a display and/or portions of a display as output secondary are discussed above, such as maintaining a lower display resolution and/or brightness for the output primary zone(s) than for output primary zone(s). In at least one implementation, the second zone can also be configured as input secondary.

Accordingly, techniques described herein provide more efficient control of display devices of a hinged device and improve the user experience by optimizing output and input characteristics of the display devices based on different usage scenarios. Further, by reducing power utilized by input devices, output devices, and sensors that are designated as secondary (e.g., not primary), implementations reduce power consumption, thus conserving power and battery life of a client device.

Having described some example implementation details, consider now a discussion of an example system and device in accordance with one or more implementations.

<FIG> illustrates an example system generally at <NUM> that includes an example computing device <NUM> that is representative of one or more computing systems and/or devices that may implement various techniques described herein. For example, the client device <NUM> discussed above with reference to <FIG> can be embodied as the computing device <NUM>. The computing device <NUM> may be, for example, a server of a service provider, a device associated with the client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

The example computing device <NUM> as illustrated includes a processing system <NUM>, one or more computer-readable media <NUM>, and one or more Input/Output (I/O) Interfaces <NUM> that are communicatively coupled, one to another. Although not shown, the computing device <NUM> may further include a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.

The processing system <NUM> is representative of functionality to perform one or more operations using hardware. Accordingly, the processing system <NUM> is illustrated as including hardware element <NUM> that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements <NUM> are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions.

The computer-readable media <NUM> is illustrated as including memory/storage <NUM>. The memory/storage <NUM> represents memory/storage capacity associated with one or more computer-readable media. The memory/storage <NUM> may include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage <NUM> may include fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable media <NUM> may be configured in a variety of other ways as further described below.

Input/output interface(s) <NUM> are representative of functionality to allow a user to enter commands and information to computing device <NUM>, and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice recognition and/or spoken input), a scanner, touch functionality (e.g., capacitive or other sensors that are configured to detect physical touch), motion functionality (e.g., accelerometers or other sensors that are configured to detect physical motion), a camera (e.g., which may employ visible or non-visible wavelengths such as infrared frequencies to detect movement that does not involve touch as gestures), six degrees of freedom controllers such as used in virtual reality and augmented reality technologies, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, tactile-response device, head mounted displays (e.g., for virtual reality and augmented reality applications), and so forth. Thus, the computing device <NUM> may be configured in a variety of ways as further described below to support user interaction.

Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The terms "module," "functionality," "entity," and "component" as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.

"Computer-readable storage media" may refer to media and/or devices that enable persistent storage of information in contrast to mere signal transmission, carrier waves, or signals per se. Computer-readable storage media do not include signals per se. The computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and which may be accessed by a computer.

"Computer-readable signal media" may refer to a signal-bearing medium that is configured to transmit instructions to the hardware of the computing device <NUM>, such as via a network. Signal media typically may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or other transport mechanism. Signal media also include any information delivery media. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

As previously described, hardware elements <NUM> and computer-readable media <NUM> are representative of instructions, modules, programmable device logic and/or fixed device logic implemented in a hardware form that may be employed in some implementations to implement at least some aspects of the techniques described herein. Hardware elements may include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware devices. In this context, a hardware element may operate as a processing device that performs program tasks defined by instructions, modules, and/or logic embodied by the hardware element as well as a hardware device utilized to store instructions for execution, e.g., the computer-readable storage media described previously.

Combinations of the foregoing may also be employed to implement various techniques and modules described herein. Accordingly, software, hardware, or program modules and other program modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements <NUM>. The computing device <NUM> may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of modules that are executable by the computing device <NUM> as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements <NUM> of the processing system. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices <NUM> and/or processing systems <NUM>) to implement techniques, modules, and examples described herein.

As further illustrated in <FIG>, the example system <NUM> enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. Services and applications run substantially similar in all three environments for a common user experience when transitioning from one device to the next while utilizing an application, playing a video game, watching a video, and so on.

In the example system <NUM>, multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one implementation, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link.

In one implementation, this interconnection architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the delivery of an experience to the device that is both tailored to the device and yet common to all devices. In one implementation, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices may be defined by physical features, types of usage, or other common characteristics of the devices.

In various implementations, the computing device <NUM> may assume a variety of different configurations, such as for computer <NUM>, mobile <NUM>, and television <NUM> uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device <NUM> may be configured according to one or more of the different device classes. For instance, the computing device <NUM> may be implemented as the computer <NUM> class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.

The computing device <NUM> may also be implemented as the mobile <NUM> class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a wearable device (e.g., a watch, glasses, an article of clothing, etc.), a multi-screen computer, and so on. The computing device <NUM> may also be implemented as the television <NUM> class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on.

The techniques described herein may be supported by these various configurations of the computing device <NUM> and are not limited to the specific examples of the techniques described herein. For example, functionalities discussed with reference to the client device <NUM> may be implemented all or in part through use of a distributed system, such as over a "cloud" <NUM> via a platform <NUM> as described below.

Claim 1:
A system (<NUM>, <NUM>) for configuring a display device as output primary, the system comprising:
an apparatus (<NUM>) having a first display device (<NUM>) and a second display device (<NUM>) physically connected to each other and hingeably moveable relative to each other about a hinge portion;
at least one processor (<NUM>); and
at least one computer-readable storage (<NUM>) media storing instructions that are executable by the at least one processor to perform operations including:
determining (<NUM>) a likely intended usage of the first display device relative to the second display device based on a state condition of the apparatus;
ascertaining based (<NUM>) on the likely intended usage that the first display device is likely intended to be used as a primary output device;
configuring (<NUM>) output functionality of the first display device as output primary by maintaining one or more of a higher display resolution for the first display device than for the second display device, or a higher display brightness for the first display device than for the second display device; and
configuring input functionality of the first display device as input secondary by:
maintaining a lower touch sensor sensitivity for the first display device than for the second display device, or
implementing a lower touch sensor sampling rate for the first display device than for the second display device,
wherein the first display device configured as input secondary is operable to receive touch input.