moving the
mouse causes the cursor to jump erratically around the screen, almost
exclusively in the vertical direction, along with rio registering button
presses even though I'm not pressing any.
This happens when the usb keyboard/mouse driver misinterprets the HID
protocol description in the
This happens to me sporadically on ThinkPad T400. I can fix it by rebooting.
--
Aram Hăvărneanu
Hi,
I want to drive a small (180x32 pixel) VFD display from plan9.
It talks i2c and can be driven as a text or graphics device.
One irritation is it aligns bitmap bytes verticaly. i.e. the display's
memory map appears to be a tradational 32x180 pixel display.
I am going to talk to this from a
I have the same firmware, and an ibm m-u0013-o 3 button mouse, on a pi2 and
it's working fine.
I will try my pi1 tonight if I get time.
Steve
On 6 May 2015, at 00:34, Paul Ivanov p...@berkeley.edu wrote:
Hello 9fans,
I just got a used 3 button USB mouse (IBM-M-U35) which is giving me
wsys: https://bitbucket.org/yiyus/devwsys-prev/
Mmm, not sure this is what I want.
I want the Pi to run plan9, and run a seccond display
(the vfd) on plan9 completely in user space.
It is an interesting project.
Personally I still harbour a wish to get a cpu server
running on windows -
Thinking out loud:
Most VFD's that I've dealt with were largely text displays - normally you'd
see an 8051 or similar driving a mess of shift registers. Essentially, one
would jam an ascii byte over GPIO and toggle a latch to update the display.
I'm assuming it will be somewhat similar for this
On 6 May 2015 at 11:52, Steve Simon st...@quintile.net wrote:
Could I run the plan9 graphics subsystem in a stand alone app rather
than involving the kernel?
I think I can but are there any examples of this?
wsys: https://bitbucket.org/yiyus/devwsys-prev/
It runs in unix. If you have a way to
On 6 May 2015 at 22:28, David du Colombier 0in...@gmail.com wrote:
Since the problem only happen when Fossil or vacfs are running
on the same machine as Venti, I suppose this is somewhat related
to how TCP behaves with the loopback.
Interesting. That would explain the clock-like delays.
Definitely interesting, and explains why I've never seen the regression (I
switched to a dedicated venti server a couple of years ago). Were these the
changes that erik submitted? ISTR him working on reno bits somewhere around
there...
On Wed, May 6, 2015 at 4:28 PM, David du Colombier
On 6 May 2015 at 23:35, Steven Stallion sstall...@gmail.com wrote:
Were these the changes that erik submitted?
I don't think so. Someone else submitted a different set of tcp changes
independently much earlier.
Just to be sure, I tried again, and the issue is not related
to the lock change on 2013-09-19.
However, now I'm sure the issue was caused by a kernel
change in 2013.
There is no problem when running a kernel from early 2013.
--
David du Colombier
Since the problem only happen when Fossil or vacfs are running
on the same machine as Venti, I suppose this is somewhat related
to how TCP behaves with the loopback.
--
David du Colombier
On 6 May 2015 at 21:55, David du Colombier 0in...@gmail.com wrote:
However, now I'm sure the issue was caused by a kernel
change in 2013.
There is no problem when running a kernel from early 2013.
Welly, welly, welly, well. That is interesting.
I got it!
The regression was caused by the NewReno TCP
change on 2013-01-24.
https://github.com/0intro/plan9/commit/e8406a2f44
--
David du Colombier
On Wed May 6 15:30:24 PDT 2015, charles.fors...@gmail.com wrote:
On 6 May 2015 at 22:28, David du Colombier 0in...@gmail.com wrote:
Since the problem only happen when Fossil or vacfs are running
on the same machine as Venti, I suppose this is somewhat related
to how TCP behaves with the
On Tue May 5 15:54:45 PDT 2015, ara...@mgk.ro wrote:
It's pretty interesting that at least three people all got exactly
150kB/s on vastly different machines, both real and virtual. Maybe the
number comes from some tick frequency?
i might suggest altering HZ and seeing if there is a throughput
On Wed May 6 14:28:03 PDT 2015, 0in...@gmail.com wrote:
I got it!
The regression was caused by the NewReno TCP
change on 2013-01-24.
https://github.com/0intro/plan9/commit/e8406a2f44
if you have proof, i'd be interested in reproduction of the issue from the
original source, or
perhaps
17 matches
Mail list logo
