Device capabilities detection/filtering
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:
- ubuntu-12.04-beta-1
- Started by
- David Pitkin
- Completed by
Related branches
Related bugs
Bug #665249: The Software Center contains no information about minimum requirements | Fix Released |
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/
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-
[server] implement UI in the sofware-
--
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:/
look at checkbox/
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:
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-
provide a simple drop-down on the agent where you can select features
Initial Scope:
work-
requires-
regions
Work Items
Dependency tree
* Blueprints in grey have been implemented.