This happens to me sporadically on ThinkPad T400. I can fix it by rebooting.
--
Aram Hăvărneanu
> 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
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 ras
On 6 May 2015 at 11:52, Steve Simon 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 control your sc
> 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 - probab
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 di
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
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
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 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 <0in...@gma
On 6 May 2015 at 23:35, Steven Stallion 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.
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
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
perh
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 throughp
> NOW is defined as MACHP(0)->ticks, so this is a pretty course timer
> that can't go backwards on intel processors. this limits the timer's
> resolution to HZ,
> which on 9atom is 1000, and 100 on pretty much anything else. further
> limiting the
> resolution is the tcp retransmit timers which
17 matches
Mail list logo
