Device capabilities detection/filtering

Registered by Michael Vogt on 2011-10-30

Provide a flexible way to filter for specific device capabilities like e.g. hardware opengl to avoid people downloading apps that will not run on their system.

Blueprint information

Status:
Started
Approver:
David Pitkin
Priority:
High
Drafter:
Michael Vogt
Direction:
Approved
Assignee:
Michael Vogt
Definition:
Approved
Series goal:
Accepted for precise
Implementation:
Good progress
Milestone target:
milestone icon ubuntu-12.04-beta-1
Started by
David Pitkin on 2012-01-26

Whiteboard

=== GOAL ===
Software-center needs to have some idea about the device capabilities that the system supports. This is important to e.g. filter out applications that require a certain hardware or to show that a certain app is
not well supported because of a missing device. Its also important when ubuntu runs on more form-factors
than just a desktop system. This also includes checking if specific devices are used to their full potential (e.g. nvidia based cards that may need additional drivers). This work consists of multiple parts:
* define device capabilites
* client side code for gathering the relevant device capabilities
* provide filtering capabilites in s-c and information in the details view

Work items:
Define format to store the device capabilities metadata along with the Package information (debtags): DONE
Discuss addition of high level profiles like "tablet" that assumes certain features: POSTPONED
Get in touch with debtags upstream about the possiblity to use Debtags for this (and discuss hardware::opengl): DONE
Check what jockey is doing: DONE
Check what jockey can do to help us (e.g. if you have nvidia and need the binary driver but its not installed yet): POSTPONED
Define how to communicate minimal requirements vs recommended requirements: POSTPONED
Figure out what to do about devices like the tranformer that can have a keyboard when its docked or modern devices where you dock your phone into your TV: POSTPONED
Make is possible for the user to opt-in/out of the device capable filtering: POSTPONED
Look at checkbox/ubuntu-friendly for gathering data (e.g. xinput provides multitouch data): DONE
Define API/lib that s-c uses to gather the device capabilities (in upstream debtags): DONE
Write client side library/code that can be used to get information about the capabilities of the system: DONE
Implement initial capability hardware opengl: DONE
Implement initial capability screen resolution: POSTPONED
Implement region information: DONE
Implement opengl driver blacklist: DONE
[mpt] design device capabilities UI for the software-center-agent (bug 916108): DONE
[server] implement UI in the sofware-center-agent to set device capabilities: DONE

--

Notes
instead of going after devices, do it for device-classes like phone, tablet, desktop and define what that means (Ubuntu Tablet 1.0 requires multitouch, min 800x480 resolution, speaker, mic)
age ratings/content ratings tags and make sure this is displayed in the UI but not necessarily be enforced in the client (as a root user can bypass it anyway)
for opengl provide something like pcmark to get a score for the hardware
How Unity does 3d Checking: https://wiki.ubuntu.com/DemystifyingUnityGraphicsHardwareRequirements
look at checkbox/ubuntu-friendly for some checks
xinput provide info about multitouch
start small by just providing textual info about the requirements and later build up using the hardwarelib
if the vendors provide a performance test benchmark, we need to add metadata to the app itself so that we can show a run-demo button before the purchase to ensure that the user can actually run it

= Session notes =

Goals:
- identify system capabilities like
   - screensize
   - opengl support
   - gps
- identify region
- age ratings
- languages that its translated into
How to do it in ubuntu/s-c?

    use debtags and have feature:: prefix there (feature::location::gps) (get in touch with enrico about prefix)

    have system lib/dbus service that can be used to query "can i haz feature"? and gimme all features

    provide plugins so that packages can provide feature, e.g. bryce could have a opengl-tester package that provides works-with-hardware::gl-level1 and that is run at dbus launch/s-c startup (needs to be async though of course)

    provide a simple drop-down on the agent where you can select features

Initial Scope:

    work-with-hardware::xs-screen, xss-screen, small-screen, medium-screen
    requires-hardware::hardware-gl-level1 (or some other abstract metric, talk to bryce about details)
    regions

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.