Hi,
android-input in Mir used to have a working logging scheme where you
could filter log messages by priority (critical, debug, informational,
etc) and tag. "Tag" being a way to specify that you want only messages
from certain areas of the code, such as "InputReader", "EventHub",
"InputDispa
On 26/09/13 02:52, Neal Peacock wrote:
I'm running down a touch screen input problem and I'm trying to figure
out the right place to look. I am porting ubuntu touch and the using
mir. My last issue is the touch screen input. I was getting some
very erratic results and I'm trying to figure ou
On 26/09/13 10:32, Daniel d'Andrada wrote:
Running mir_demo_standalone_inputfilter as root is the best way to
diagnose input issues. If you're using the latest mir (from bzr repo),
to get log messages from android-input you will also have to set a
ANDROID_LOG_TAGS environmen
On 02/10/13 00:10, Daniel van Vugt wrote:
Do we have a roadmap for how to deal with the future of Mir input?
I mean, Mir uses Android input. When there's a bug or missing feature,
do we intend to maintain and branch the Android input code? Is that
more desirable than Mir having its own impleme
On 15/10/13 10:01, Kevin Gunn wrote:
What do you think of using blueprints for bugs-which-are-really-features ?
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assig
On 15/10/13 11:09, Michał Sawicz wrote:
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priori
st found the bug (which itself is actually a feature
request)
and it looks unlikely to be resolved:
https://bugs.launchpad.net/__launchpad/+bug/176431
<https://bugs.launchpad.net/launchpad/+bug/176431>
On 15/10/13 22:09, Michał Sawicz wrote:
Hi Christopher,
The job of EventHub, in short, is multiplexing the event streams from
all those /dev/input/event* files into a single output stream of events
(those events then having device ids to identify from which device they
come from).
To me it looks like a very clear-cut task. Thus I
On 12/11/13 21:57, Christopher James Halse Rogers wrote:
I think we might have different stages of cooking here :). I want the
events leaving EventHub to be a usefully accurate representation of the
user's interaction with the input device. There are further stages of
cooking needed after that -
Hi,
On November 26th I (Unity8), Kevin Gunn, Chris Gagnon (Autopilot) and
Alexandros Frantzis (Mir) had a meeting on the requirements and
implementation of screenshotting and screencasting.
Chris told us that what autopilot really wants is screencasting (not
screen shots) as it records all t
On 26/11/13 10:31, Daniel d'Andrada wrote:
On November 26th [...]
s/26/25
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
On 27/11/13 04:33, Thomas Voß wrote:
On Wed, Nov 27, 2013 at 2:38 AM, Daniel van Vugt
wrote:
>On an implementation note...
>
>I think adding yet more library dependencies (dbus) to Mir would be a
>mistake. It's already quite bloated in that respect.
>
+1, Mir should expose the required functi
On 28/03/14 17:47, Mirco Müller wrote:
Am 28.03.2014 20:48, schrieb Kevin DuBois:
...
Given this, what I would want is mir to handle all the junk about
clients, ipc, buffer swapping, etc. I'd just want to write GL; my own
shaders, my own algorithms, my own GL state. [3] I wouldn't really be
inte
On 11/08/14 14:09, Gerry Boland wrote:
[...]
Thoughts?
-Gerry
I've yet another suggestion:
unity8 provides a D-Bus API for autopilot to ask "hey, what's the
position/transformation of surface X?". Then AP would apply that
transformation to a surface local coordinate and send the resulting
On 13/08/14 10:12, Gerry Boland wrote:
On 13/08/14 13:59, Daniel d'Andrada wrote:
I've yet another suggestion:
unity8 provides a D-Bus API for autopilot to ask "hey, what's the
position/transformation of surface X?". Then AP would apply that
transformation to a sur
On 22/01/15 06:23, Daniel van Vugt wrote:
> Looking at an example of changing from the old input event API to the
> new one in Mir 0.10:
>
> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2246?compare_revid=2128#examples/fingerpaint.c
>
>
> You can see it requires a lot more
On 04/02/2015 15:00, Daniel van Vugt wrote:
Hi all (and this is directed mostly at the wider world outside of
mir-team), a quick poll:
Which of these names makes more sense to you?
MirTouchInput = read_all_fingers();
MirTouchEvent = read_all_fingers();
MirTouchInputEvent = read_all_fingers();
On 05/10/2015 22:27, Daniel van Vugt wrote:
It also became apparent those X cursors are unusably small on a 4K
display. We do have bigger ones for Unity7 but I don't know where that
cursor theme switching happens.
Cursors in dmz-cursor-theme (the one Unity 7&8 uses) come in 3 different
siz
On 03/12/2015 00:21, Daniel van Vugt wrote:
Unity8's stretchy/jiggly resizing was fix released 3 days ago apparently:
https://bugs.launchpad.net/qtmir/+bug/1497083
Only the unity8 part. The qtmir one still hasn't landed (but it's in a
silo already):
https://code.launchpad.net/~dandrader/
Hi,
I was working under the assumption that, in mir::scene::Surface,
input_bounds() was the bounding box of the input region [1]. But it was
always returning the full surface size no matter what.
Then, checking implementation, I saw that it simply returns the surface
size. Is that the correc
rough to the surface below.
On 04/06/16 13:38, Alan Griffiths wrote:
On 03/06/16 21:17, Daniel d'Andrada wrote:
Hi,
I was working under the assumption that, in mir::scene::Surface,
input_bounds() was the bounding box of the input region [1]. But it
was always returning the full surface s
21 matches
Mail list logo
