linuxconsole-dev

Re: AW: Multiple text consoles

[Matan Ziv-Av <ma...@sv...>]

On Fri, 3 Feb 2006, Aivils Stoss wrote:

> On Ceturtdiena, 2. Febru=E2ris 2006 21:22, Matan Ziv-Av wrote:
>>> Multiple VGA text consoles seems difficult (Avilis pointed out that onl=
y
>>> one VGA device per PCI domain is allowed) - I really know too little
>>> about it, but it seems to me that one runs into BIOS/Hardware issues
>>> that make more than one VGA device impossible.
>>
>> Actually, multiple VGA text consoles are not that hard. Most PCI card
>> allow alternate access to both VGA registers and VGA memory thru the PCI
>> regions.
>> I adapted vgacon to work on nvidia and matrox cards:
>> http://www.arava.co.il/matan/misc/textcon.tgz
>> but it should be easy to make it more generic.
>
> So if nvvgacon does not take over vgacon, then it is completely independ?
> Can i run multiple nvvgacon simultaneous, if pci bus id specified
> for each instance?

The console output is independent. I use with a standarad kernel and a=20
userspace program that injects keyboard events to specified console, to=20
emulate a two console system.
The module needs to be changed a little to support multiple=20
nvvga consoles, but it can also be done by inserting the module multiple=20
times (after renaming it).

> Is necessary XFree int10 real mode initialisation for each instance?

Yes. Though it can be done with x86emu directly, without using XFree for=20
this.

> From where You get magic values for ioremap()?

I tried every address that ends with 0x3d4, and so which one behaves=20
like the CRTC port.


--=20
Matan Ziv-Av.                         ma...@sv...

Re: AW: Multiple text consoles

[Aivils S. <ai...@un...>]

On Ceturtdiena, 2. Febru=E2ris 2006 21:22, Matan Ziv-Av wrote:
> > Multiple VGA text consoles seems difficult (Avilis pointed out that only
> > one VGA device per PCI domain is allowed) - I really know too little
> > about it, but it seems to me that one runs into BIOS/Hardware issues
> > that make more than one VGA device impossible.
>
> Actually, multiple VGA text consoles are not that hard. Most PCI card
> allow alternate access to both VGA registers and VGA memory thru the PCI
> regions.
> I adapted vgacon to work on nvidia and matrox cards:
> http://www.arava.co.il/matan/misc/textcon.tgz
> but it should be easy to make it more generic.

So if nvvgacon does not take over vgacon, then it is completely independ?
Can i run multiple nvvgacon simultaneous, if pci bus id specified
for each instance?
Is necessary XFree int10 real mode initialisation for each instance?
=46rom where You get magic values for ioremap()?

Aivils

Re: AW: Multiple text consoles

[Matan Ziv-Av <ma...@sv...>]

On Thu, 2 Feb 2006, ludovic pollet wrote:

> Your work is really interresting !
>
> Does your driver actually disable NV vga ioports ?
>
> In my case, that could be helpfull :
>
> My computer runs with a MGA and a NVIDIA board. Sometime, the nvidia head
> seems to be messed up when X starts on the MGA board. I believe that the X
> mga driver directly accesses the VGA ioports which belong to the NV board.
>
> So, with nvvgacon I may have a vga console on the NV card which would not
> require VGA ioports access. If your driver disable VGA ioport on the NV
> board, I'll be sure that no more conflict will arise !

The driver does not disable the vga ports.
You can disable them by disallowing all IO access to the card in PCI 
config (bit 0 of command register). (not related to driver).
Please note that the driver only works on NV3 (Riva128) cards. If you 
want to use it on a newer card, it will need a few changes.


-- 
Matan Ziv-Av.                         ma...@sv...

Re: AW: Multiple text consoles

[ludovic p. <pl...@nn...>]

Your work is really interresting !

Does your driver actually disable NV vga ioports ?=20

In my case, that could be helpfull :

My computer runs with a MGA and a NVIDIA board. Sometime, the nvidia head=
=20
seems to be messed up when X starts on the MGA board. I believe that the =
X=20
mga driver directly accesses the VGA ioports which belong to the NV board=
.

So, with nvvgacon I may have a vga console on the NV card which would not=
=20
require VGA ioports access. If your driver disable VGA ioport on the NV=20
board, I'll be sure that no more conflict will arise !

Regards,

Ludovic P


Le Jeudi 2 F=E9vrier 2006 20:22, Matan Ziv-Av a =E9crit :
> On Tue, 31 Jan 2006, Unger Richard wrote:
> > Multiple VGA text consoles seems difficult (Avilis pointed out that o=
nly
> > one VGA device per PCI domain is allowed) - I really know too little
> > about it, but it seems to me that one runs into BIOS/Hardware issues
> > that make more than one VGA device impossible.
>
> Actually, multiple VGA text consoles are not that hard. Most PCI card
> allow alternate access to both VGA registers and VGA memory thru the PC=
I
> regions.
> I adapted vgacon to work on nvidia and matrox cards:
> http://www.arava.co.il/matan/misc/textcon.tgz
> but it should be easy to make it more generic.

--=20
"And I doubt complaining to the author gets you anything but a free procm=
ail
 rule."

	- Alan Cox on asking authors to document their code

Re: AW: Multiple text consoles

[Matan Ziv-Av <ma...@sv...>]

On Tue, 31 Jan 2006, Unger Richard wrote:

> Multiple VGA text consoles seems difficult (Avilis pointed out that only
> one VGA device per PCI domain is allowed) - I really know too little
> about it, but it seems to me that one runs into BIOS/Hardware issues
> that make more than one VGA device impossible.

Actually, multiple VGA text consoles are not that hard. Most PCI card 
allow alternate access to both VGA registers and VGA memory thru the PCI 
regions.
I adapted vgacon to work on nvidia and matrox cards:
http://www.arava.co.il/matan/misc/textcon.tgz
but it should be easy to make it more generic.


-- 
Matan Ziv-Av.                         ma...@sv...

Re: X11R7.0

[Aivils S. <ai...@un...>]

On Tre=F0diena, 1. Febru=E2ris 2006 16:57, Zephaniah E. Hull wrote:
> On Wed, Feb 01, 2006 at 09:34:20AM +0200, Aivils Stoss wrote:
> > On Otrdiena, 31. Janv=E2ris 2006 22:19, Zephaniah E. Hull wrote:
> > > > Also one version before latest will not work proper if i
> > > > create/delete devices in the runtime. It is not official but i
> > > > provide this one:
> > > > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2
> > > > This package contains xmodule, which allow load/remove X server
> > > > modules and xdevice, which allow create/delete X server input devic=
es
> > > > at runtime. Existing input drivers are compatible with xdevice,
> > > > but Your not. Even xdevice never goes into main it make life easy
> > > > during development. You don't need server restart on new driver
> > > > version or on device parameter change. Fatal errors still are fatal.
> > > > Syntaxis like this:
> > > > # xmodule -l evdev
> > > > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1
> > > > You driver changes device indentifier unwarranted. You must search
> > > > new device
> > > > # xsetpointer -l
> > > > normal device delete uses same identifier
> > > > # xdevice -d e1
> > >
> > > That looks handy, however due to hotplug support my driver is going to
> > > cause, interesting issues.
> > >
> > > Mainly, we create new driver instances for additional devices that are
> > > plugged in that match the specification for current devices.
> > >
> > > Because we need the new entries to be uniquely identifiable, we append
> > > the phys to the name.
> > >
> > > At this time there is no way around this.
> > >
> > > Also at the moment I'm not using a modular tree, which makes using th=
at
> > > a bit harder even for testing purposes.
> >
> > That package didn't use compile form scratch. All what You need is X
> > server source for headers, runing X binary for some variables, gcc, X
> > server restart is necessary. I use it under my 6.8.2.
> >
> > xdevice was developed keeping in mind buch of all input devices. It does
> > "hotplug" in large-scale without touching driver source.
> > Seems SIGHUP is sacred. Even aiptek tablet developers did not replay.
> > From my point of view looks very stupid - plug new input device and then
> > restart X for new config.
>
> After taking a closer look at it, it's a nice idea, but I'd suggest
> sitting down and considering the design and all implications for a
> while.
>
> Among other things, the kernel ioctl interface is a rather poor one to
> emulate, while at first glance it looks fairly easy to deal with, it has
> some noticeable scale issues as far as maintance goes.

I think poor thing is writing 24 indentical requests instead one.
May be i change my mind sometimes.

> Take a look at some of the protocol discussions in the X.org wiki on the
> Hotplug subject, and keep trying.

I have troubles. It's ready.

> (The evdev driver is nowhere even close to being the first, second, or
> probably even eighth design for it that I actually wrote the code for,
> never mind that I've had.  And it still has some design issues that I
> need to fix.)
>
> Zephaniah E. Hull.
> (Spelling not guaranteed this time around, I'm tired and going to bed.)

Aivils

Re: X11R7.0

[Zephaniah E. H. <wa...@ae...>]

On Wed, Feb 01, 2006 at 09:34:20AM +0200, Aivils Stoss wrote:
> On Otrdiena, 31. Janv=C4=81ris 2006 22:19, Zephaniah E. Hull wrote:
> > > Also one version before latest will not work proper if i create/delete
> > > devices in the runtime. It is not official but i provide this one:
> > > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2
> > > This package contains xmodule, which allow load/remove X server
> > > modules and xdevice, which allow create/delete X server input devices
> > > at runtime. Existing input drivers are compatible with xdevice,
> > > but Your not. Even xdevice never goes into main it make life easy
> > > during development. You don't need server restart on new driver
> > > version or on device parameter change. Fatal errors still are fatal.
> > > Syntaxis like this:
> > > # xmodule -l evdev
> > > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1
> > > You driver changes device indentifier unwarranted. You must search new
> > > device
> > > # xsetpointer -l
> > > normal device delete uses same identifier
> > > # xdevice -d e1
> >
> > That looks handy, however due to hotplug support my driver is going to
> > cause, interesting issues.
> >
> > Mainly, we create new driver instances for additional devices that are
> > plugged in that match the specification for current devices.
> >
> > Because we need the new entries to be uniquely identifiable, we append
> > the phys to the name.
> >
> > At this time there is no way around this.
> >
> > Also at the moment I'm not using a modular tree, which makes using that
> > a bit harder even for testing purposes.
>=20
> That package didn't use compile form scratch. All what You need is X serv=
er
> source for headers, runing X binary for some variables, gcc, X server res=
tart
> is necessary. I use it under my 6.8.2.
>=20
> xdevice was developed keeping in mind buch of all input devices. It does
> "hotplug" in large-scale without touching driver source.
> Seems SIGHUP is sacred. Even aiptek tablet developers did not replay.
> From my point of view looks very stupid - plug new input device and then
> restart X for new config.

After taking a closer look at it, it's a nice idea, but I'd suggest
sitting down and considering the design and all implications for a
while.

Among other things, the kernel ioctl interface is a rather poor one to
emulate, while at first glance it looks fairly easy to deal with, it has
some noticeable scale issues as far as maintance goes.

Take a look at some of the protocol discussions in the X.org wiki on the
Hotplug subject, and keep trying.

(The evdev driver is nowhere even close to being the first, second, or
probably even eighth design for it that I actually wrote the code for,
never mind that I've had.  And it still has some design issues that I
need to fix.)

Zephaniah E. Hull.
(Spelling not guaranteed this time around, I'm tired and going to bed.)

--=20
	  1024D/E65A7801 Zephaniah E. Hull <wa...@ae...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

<nonlinear> .net is microsofts perverted version of a java networked
             environment uglified for windows-specific crap
	-- nonlinear in #opengl

AW: AW: AW: AW: Kernel Version

[Unger R. <ric...@te...>]

Wastebox?  :)  -> What do you mean?

Seriously, it looked to me like there were files checked in by you - has =
that changed?

Richard

=20

> -----Urspr=FCngliche Nachricht-----
> Von: lin...@li...=20
> [mailto:lin...@li...] Im=20
> Auftrag von Aivils Stoss
> Gesendet: Mittwoch, 01. Februar 2006 11:25
> An: lin...@li...
> Betreff: Re: AW: AW: AW: Kernel Version
>=20
> On Tre=F0diena, 1. Febru=E2ris 2006 12:05, Unger Richard wrote:
> > Aivils can commit - perhaps he can add you as a developer?
>=20
> I cannot commit, because i think that linuxconsole CVS is a=20
> waste box. I am not admin.
>=20
> Aivils
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20

Re: AW: AW: AW: Kernel Version

[Aivils S. <ai...@un...>]

On Tre=C5=A1diena, 1. Febru=C4=81ris 2006 12:05, Unger Richard wrote:
> Aivils can commit - perhaps he can add you as a developer?

I cannot commit, because i think that linuxconsole CVS is
a waste box. I am not admin.

Aivils

AW: AW: AW: Kernel Version

[Unger R. <ric...@te...>]

DQpUaGF0IHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHJlcXVpcmVtZW50IC0gYSAxNTBLIHBhdGNo
IHdvdWxkIGJlIGEgYml0IHNjYXJ5IDopDQoNClJpY2hpZQ0KDQoNCj4gLS0tLS1VcnNwcsO8bmds
aWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IFpvbHRhbiBCb3N6b3JtZW55aSBbbWFpbHRvOnpi
b3N6b3JAZnJlZW1haWwuaHVdIA0KPiBHZXNlbmRldDogRGllbnN0YWcsIDMxLiBKw6RubmVyIDIw
MDYgMTk6MDkNCj4gQW46IFVuZ2VyIFJpY2hhcmQNCj4gQ2M6IEFpdmlscyBTdG9zczsgbGludXhj
b25zb2xlLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gQmV0cmVmZjogUmU6IEFXOiBBVzog
S2VybmVsIFZlcnNpb24NCj4gDQo+IFVuZ2VyIFJpY2hhcmQgw61ydGE6DQo+IA0KPiA+OikNCj4g
Pg0KPiA+V2VsbCwgSSBkb24ndCBrbm93IGFib3V0IGFuICdvZmZlbnNpdmUnIC0gSSB0aGluayB0
aGF0IG1pZ2h0IA0KPiBiZSBkaWZmaWN1bHQuDQo+ID4NCj4gPkJ1dCBJIHRoaW5rIGEgZ29vZCB0
aGluZyB0byBkbyB3b3VsZCBiZSB0byBrZWVwIHRoZSANCj4gbGludXhjb25zb2xlIHNpdGUgdXAg
dG8gZGF0ZSBhbmQgYWN0aXZlLiBJIHRoaW5rIHRoZXJlIGlzIA0KPiBpbnRlcmVzdCBpbiB0aGlz
IHByb2plY3QsIGFuZCBJIHRoaW5rIGdvb2QgZGVzaWducyB3aWxsIA0KPiBldmVudHVhbGx5IGJl
IGFjY2VwdGVkIGludG8gdGhlIGtlcm5lbC4uLiANCj4gPg0KPiA+SSB0aGluayBpdCBpcyBwcm9i
YWJseSBhIG1hdHRlciBvZiB0aW1lLCBzbyBJIHRoaW5rIGEgDQo+ICdzaWVnZScgd291bGQgYmUg
DQo+ID5iZXR0ZXIgdGhhbiBhbiAnb2ZmZW5zaXZlJyA7KQ0KPiA+DQo+ID5XaGF0IGFyZSB0aGUg
b2JqZWN0aW9ucyB0byB0aGUgbGludXhjb25zb2xlIGNvZGU/DQo+ID4NCj4gPlJpY2hpZQ0KPiA+
ICANCj4gPg0KPiANCj4gVGhlIG9iamVjdGl2ZSAod2VsbCwgSSB3b3VsZCBjYWxsIGl0IHJlcXVp
cmVtZW50KSAgd2FzIHRvIA0KPiBzcGxpdCBpdCB1cCB0byBzbWFsbGVyIHBpZWNlcy4NCj4gTm8g
b25lIHdvdWxkIGxvb2sgYXQgYSBwYXRjaCBhYm91dCAxNTBLLCBpdCBjb250YWlucyB0b28gbWFu
eSANCj4gY2hhbmdlcyBhdCBvbmNlLg0KPiBTbWFsbGVyIGxvZ2ljYWwgcGllY2VzIGNhbiBiZSBy
ZXZpZXdlZCBlYXNpbHkgYW5kIGFjY2VwdGVkIA0KPiBpbnRvIHRoZSAtbW0gdHJlZSBmaXJzdCBl
dmVuIGlmIGl0IGJyZWFrcyBzb21ldGhpbmcuDQo+IA0KPiA+IA0KPiA+DQo+ID4gIA0KPiA+DQo+
ID4+LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiA+PlZvbjogQWl2aWxzIFN0
b3NzIFttYWlsdG86YWl2aWxzQHVuaWJhbmthLmx2XSANCj4gPj5HZXNlbmRldDogRGllbnN0YWcs
IDMxLiBKw6RubmVyIDIwMDYgMDk6MDgNCj4gPj5BbjogbGludXhjb25zb2xlLWRldkBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQNCj4gPj5DYzogVW5nZXIgUmljaGFyZDsgWm9sdGFuIEJvc3pvcm1lbnlp
DQo+ID4+QmV0cmVmZjogUmU6IEFXOiBLZXJuZWwgVmVyc2lvbg0KPiA+Pg0KPiA+Pk9uIFBpcm1k
aWVuYSwgMzAuIEphbnbEgXJpcyAyMDA2IDE5OjMyLCBab2x0YW4gQm9zem9ybWVueWkgd3JvdGU6
DQo+ID4+ICAgIA0KPiA+Pg0KPiA+Pj5IaSwNCj4gPj4+DQo+ID4+PkFpdmlscyBTdG9zcyDDrXJ0
YToNCj4gPj4+ICAgICAgDQo+ID4+Pg0KPiA+Pj4+T24gUGlybWRpZW5hLCAzMC4gSmFudsSBcmlz
IDIwMDYgMTA6MDUsIFVuZ2VyIFJpY2hhcmQgd3JvdGU6DQo+ID4+Pj4gDQo+ID4+Pj4NCj4gPj4+
PiAgICAgICAgDQo+ID4+Pj4NCj4gPj4+Pj5IaSENCj4gPj4+Pj4NCj4gPj4+Pj5UaGFua3MgZm9y
IHRoZSB0aXAsIEkgc2hvdWxkIG9idmlvdXNseSBoYXZlIGNoZWNrZWQgZm9yIHRhZ3MuLi4NCj4g
Pj4+Pj4NCj4gPj4+Pj5JcyB0aGUgbGludXhjb25zb2xlIHN0dWZmIHN0aWxsIHVuZGVyIGFjdGl2
ZSBkZXZlbG9wbWVudD8NCj4gPj4+Pj4gICANCj4gPj4+Pj4gICAgICAgICAgDQo+ID4+Pj4+DQo+
ID4+Pj5Oby4NCj4gPj4+PiANCj4gPj4+PiAgICAgICAgDQo+ID4+Pj4NCj4gPj4+SSBzdGlsbCB1
cGdyYWRlIHRoZSBrZXJuZWwgcGF0Y2ggZm9yIGV2ZXJ5IG1ham9yIGtlcm5lbCANCj4gPj4+ICAg
ICAgDQo+ID4+Pg0KPiA+PnZlcnNpb24sIEkgYW0gDQo+ID4+ICAgIA0KPiA+Pg0KPiA+Pj5vbiAy
LjYuMTUtcnVieSBub3cuDQo+ID4+PlRob3VnaCBJIGFsd2F5cyBsZWF2ZSBvdXQgZmJkZXYgYXMg
SSBoYXZlIHRvIHVwZGF0ZSB0aGUgDQo+ID4+PiAgICAgIA0KPiA+Pj4NCj4gPj5rZXJuZWwgYXMg
c29vbiANCj4gPj4gICAgDQo+ID4+DQo+ID4+PmFzIHBvc3NpYmxlIHRvIGtlZXAgdGhlIG1hY2hp
bmUgcnVubmluZyB3aXRoIHZlcnkgbGl0dGxlIGRvd250aW1lLg0KPiA+Pj4gICAgICANCj4gPj4+
DQo+ID4+V293ISBEbyBZb3UgcGxhbiB0aGUgb2ZmZW5zaXZlPyBJIG1lYW4gc2VuZGluZyBwYXRj
aGVzIHRvIA0KPiA+PkFuZHJldyBNb3J0b24gYW5kIGZpZ2h0aW5nIGFnYWluc3QgYWdlZCBpbmhh
Yml0YW50cy4NCj4gPj4NCj4gPj5BaXZpbHMNCj4gPj4NCj4gPj4gICAgDQo+ID4+DQo+IA0KPiAN
Cg==

AW: AW: AW: Kernel Version

[Unger R. <ric...@te...>]

DQpBaXZpbHMgY2FuIGNvbW1pdCAtIHBlcmhhcHMgaGUgY2FuIGFkZCB5b3UgYXMgYSBkZXZlbG9w
ZXI/DQoNClJpY2hhcmQgDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0K
PiBWb246IFpvbHRhbiBCb3N6b3JtZW55aSBbbWFpbHRvOnpib3N6b3JAZnJlZW1haWwuaHVdIA0K
PiBHZXNlbmRldDogRGllbnN0YWcsIDMxLiBKw6RubmVyIDIwMDYgMTk6MDYNCj4gQW46IFVuZ2Vy
IFJpY2hhcmQNCj4gQ2M6IEFpdmlscyBTdG9zczsgbGludXhjb25zb2xlLWRldkBsaXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQNCj4gQmV0cmVmZjogUmU6IEFXOiBBVzogS2VybmVsIFZlcnNpb24NCj4gDQo+
IFVuZ2VyIFJpY2hhcmQgw61ydGE6DQo+IA0KPiA+SGkhDQo+ID4NCj4gPlRoYW5rcyBmb3IgYWxs
IHRoZSBpbmZvcm1hdGlvbiEhIEknbGwgbGV0IHlvdSBrbm93IGhvdyBpdCBnb2VzIChJJ20gDQo+
ID5zdXJlIHRvIGJlIGNvbmZ1c2VkIGFnYWluIDspDQo+ID4NCj4gPkNhbiBlaXRoZXIgb2YgeW91
IGNvbW1pdCB5b3VyIGNoYW5nZXMgYmFjayB0byB0aGUgU0Ygc2l0ZT8NCj4gPiAgDQo+ID4NCj4g
DQo+IEkgZG9uJ3QgaGF2ZSBjb21taXR0ZXIgYWNjZXNzIHJpZ2h0cyBpbiB0aGlzIHByb2plY3Qg
b24gU0YuDQo+IEJ1dCBJIGNhbiBwb3N0IHRoZSBsYXRlc3QgcGF0Y2ggb24gdGhlIG1haWxpbmcg
bGlzdC4gT3IgYSANCj4gZG93bmxvYWQgVVJMLg0KPiANCj4gPkl0IHNlZW1zIGEgc2hhbWUgZm9y
IGFsbCB5b3VyIGhhcmQgd29yayB0byBiZSBsb3N0Li4uDQo+ID4NCj4gPkFuZCBhcyBmb3IgeW91
ciBFbmdsaXNoLCBJIHRoaW5rIEkgdW5kZXJzdG9vZCB5b3UgdmVyeSB3ZWxsLCANCj4gc28gSSB3
b3VsZCANCj4gPmhhdmUgbm8gd29ycmllcyB0aGVyZSA6KQ0KPiA+DQo+ID5SZWdhcmRzIGZyb20g
Vmllbm5hIQ0KPiA+DQo+ID5SaWNoaWUNCj4gPg0KPiA+DQo+ID4gDQo+ID4NCj4gPiAgDQo+ID4N
Cj4gPj4tLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+ID4+Vm9uOiBBaXZpbHMg
U3Rvc3MgW21haWx0bzphaXZpbHNAdW5pYmFua2EubHZdDQo+ID4+R2VzZW5kZXQ6IE1vbnRhZywg
MzAuIErDpG5uZXIgMjAwNiAxMTozMA0KPiA+PkFuOiBVbmdlciBSaWNoYXJkDQo+ID4+Q2M6IGxp
bnV4Y29uc29sZS1kZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ID4+QmV0cmVmZjogUmU6IEFX
OiBLZXJuZWwgVmVyc2lvbg0KPiA+Pg0KPiA+Pk9uIFBpcm1kaWVuYSwgMzAuIEphbnbEgXJpcyAy
MDA2IDEwOjA1LCBVbmdlciBSaWNoYXJkIHdyb3RlOg0KPiA+PiAgICANCj4gPj4NCj4gPj4+SGkh
DQo+ID4+Pg0KPiA+Pj5UaGFua3MgZm9yIHRoZSB0aXAsIEkgc2hvdWxkIG9idmlvdXNseSBoYXZl
IGNoZWNrZWQgZm9yIHRhZ3MuLi4NCj4gPj4+DQo+ID4+PklzIHRoZSBsaW51eGNvbnNvbGUgc3R1
ZmYgc3RpbGwgdW5kZXIgYWN0aXZlIGRldmVsb3BtZW50Pw0KPiA+Pj4gICAgICANCj4gPj4+DQo+
ID4+Tm8uDQo+ID4+DQo+ID4+ICAgIA0KPiA+Pg0KPiA+Pj5XaWxsIHRoZSByZWRlc2lnbmVkIGNv
bnNvbGUgbGF5ZXIgbWFrZSBpdCBpbnRvIHRoZSBtYWlubGluZSBrZXJuZWw/DQo+ID4+PiAgICAg
IA0KPiA+Pj4NCj4gPj5TZWVtcyBuby4NCj4gPj4xKSBjb25zb2xlIGRldmVsb3BpbmcgaXMgbmln
aHRtYXJlLg0KPiA+PjIpIDk5JSBvZiB0ZXN0ZXJzIG9yIGVuZHVzZXJzIHVzZSBtdWx0aXBsZSBY
IHNlcnZlcnMgaW5zdGVhZCBvZiANCj4gPj5tdWx0aXBsZSB0ZXh0IG1vZGUgY29uc29sZXMgLSBt
dWx0aXBsZSB0ZXh0IG1vZGUgYmVjYW1lIG51dHkgDQo+ID4+ZGV2ZWxvcGVycyB0cmljay4NCj4g
Pj4zKUkgZG8gbm90IGtub3cgaG93IHRvIHdvcmsgInRlcm1pbmFsIGVtdWxhdGlvbiIuDQo+ID4+
NClJIGNhbm5vdCB3cml0ZSBpbiB0aGUgc2FuZSBFbmdsaXNoLiANCj4gPj4NCj4gPj4gICAgDQo+
ID4+DQo+ID4+PlRvIG1lIGl0IHNlZW1zIGxpa2UgYW4gb2J2aW91cyBpZGVhIHRoYXQgaWYgYSBt
dWx0aXVzZXIgc3lzdGVtIGhhcyANCj4gPj4+bXVsdGlwbGUgc2NyZWVucyBhbmQga2V5Ym9hcmRz
LCBtdWx0aXBsZSAoaW5kZXBlbmRhbnQpDQo+ID4+PiAgICAgIA0KPiA+Pj4NCj4gPj50ZXJtaW5h
bHMgc2hvdWxkIGJlIHBvc3NpYmxlLg0KPiA+PiAgICANCj4gPj4NCj4gPj4+SW4gZmFjdCwgdG8g
bWUsIGFueSBvdGhlciBzaXR1YXRpb24gaW5kaWNhdGVzIGEgbGl0dGxlIGJpdA0KPiA+Pj4gICAg
ICANCj4gPj4+DQo+ID4+b2YgYSBkZXNpZ24NCj4gPj4gICAgDQo+ID4+DQo+ID4+PnByb2JsZW0u
DQo+ID4+PiAgICAgIA0KPiA+Pj4NCj4gPj5MaW51eCBpcyBzbyBmbGV4aWJsZS4gT2J2aW91cyBy
ZWFjaCBzYW1lIHJlc3VsdCBpbiB2ZXJ5IGRpZmZlcmVudCANCj4gPj53YXlzLg0KPiA+Pg0KPiA+
PiAgICANCj4gPj4NCj4gPj4+Q3VycmVudGx5IEknbSBwbGF5aW5nIHdpdGggdGhlIDIuNi45LXJ1
Ynkga2VybmVsIEkgY29tcGlsZWQuIERvbid0IA0KPiA+Pj5oYXZlIG11Y2ggdGltZSBhcyBJIGFt
IG1vdmluZyB0aGVzZSBkYXlzLCBidXQgaXQgbG9va3MgbGlrZQ0KPiA+Pj4gICAgICANCj4gPj4+
DQo+ID4+dGhlIGtlcm5lbA0KPiA+PiAgICANCj4gPj4NCj4gPj4+Ym9vdHMgZmluZSBhbmQgdGhl
IC9kZXYvYnVzL2NvbnNvbGUgZGV2aWNlcyBhcmUgbm93IGF2YWlsYWJsZS4uLg0KPiA+Pj4NCj4g
Pj4+SSBkbyBoYXZlIGEgZmV3IHF1ZXN0aW9ucywgZG9jdW1lbnRhdGlvbiBvbiB0aGlzIGlzIHNv
IGhhcmQNCj4gPj4+ICAgICAgDQo+ID4+Pg0KPiA+PnRvIGZpbmQuLi4NCj4gPj4NCj4gPj5odHRw
Oi8vd3d3Lmx0bi5sdi9+YWl2aWxzLw0KPiA+Pg0KPiA+PiAgICANCj4gPj4NCj4gPj4+MSkgSXMg
aXQgcG9zc2libGUgdG8gaGF2ZSBtb3JlIHRoYW4gb25lIFZHQSBjb25zb2xlLA0KPiA+Pj4gICAg
ICANCj4gPj4+DQo+ID4+Tm8uDQo+ID4+DQo+ID4+ICAgIA0KPiA+Pg0KPiA+Pj5vciBpcyB0aGUg
VkdBIGNvbnNvbGUNCj4gPj4+YWx3YXlzIG9ubHkgYm91bmQgdG8gdGhlIHByaW1hcnkgZ3JhcGhp
Y3MgZGV2aWNlPyAyKSBXaGF0J3MNCj4gPj4+ICAgICAgDQo+ID4+Pg0KPiA+PnRoZSBzdGF0dXMN
Cj4gPj4gICAgDQo+ID4+DQo+ID4+Pm9uIGZyYW1lYnVmZmVyIHN1cHBvcnQ/IEFsbCB0aGUgZG9j
cyBpbmRpY2F0ZSBmcmFtZWJ1ZmZlciBjb25zb2xlIA0KPiA+Pj5pc24ndCByZWFkeQ0KPiA+Pj4t
IGlzIGl0IHdvcnRoIHRyeWluZyBvdXQgbXVsdGlwbGUgZmJjb25zPw0KPiA+Pj4gICAgICANCj4g
Pj4+DQo+ID4+RWFjaCBmYiBkZXZpY2UgKC9kZXYvZmJYWCkgYXNzaWduZWQgd2l0aCBzZXBhcmF0
ZSBjb25zb2xlLiANCj4gPj5FYWNoIHNlcGFyYXRlIGNvbnNvbGUgbWF5IGhhdmUga2V5Ym9hcmQg
ZGV2aWNlLiBMYXN0IA0KPiB3b3JraW5nIGlzIDIuNi4xMw0KPiA+Pmh0dHA6Ly93d3cubHRuLmx2
L35haXZpbHMvZmlsZXMvcnVieS0yLjYuMTMtQTAuZGlmZi5iejINCj4gPj5VbmRlciAyLjYuMTMg
a2VuZWwgZXhpc3RzIG9wdGlvbg0KPiA+PmR1bWJjb249Mzo0DQo+ID4+d2hlcmUgMyBpcyBjb3Vu
dCBvZiBkdW1teSBjb25zb2xlcywgNCBpcyBUVFkgY291bnQgcGVyIHNpbmdsZSBkdW1teSANCj4g
Pj5jb25zb2xlIEFzIHJlc3VsdCBWR0EgaGF2ZSB0dHkxLXR0eTE2IGR1bW15IDEgaGF2ZSANCj4g
dHR5MTctdHR5MjAgZHVtbXkgMiANCj4gPj5oYXZlIHR0eTIxLXR0eTI0IGR1bW15IDMgaGF2ZSB0
dHkyNS10dHkyOA0KPiA+Pg0KPiA+PlByb2JhYmx5IHNvbWVvbmUgbG9hZCBmYiBkZXYgZHJpdmVy
LCB3aGljaCBjcmVhdGVzIC9kZXYvZmIwIC0gDQo+ID4+L2Rldi9mYjMsIGFmdGVyIGZiY29uIG1v
ZHVsZSBsb2FkaW5nIHRoZXNlIGZiIGRldmljZXMgYXJlIGFzc2lnbmVkIDoNCj4gPj5mYjAgdGFr
ZXMgb3ZlciBWR0EgLSB0dHkxLXR0eTE2DQo+ID4+ZmIxIHRha2VzIG92ZXIgZHVtbXkgMSAtIHR0
eTE3LXR0eTIwDQo+ID4+ZmIyIC0gdHR5MjEtdHR5MjQNCj4gPj5mYjMgLSB0dHkyNS10dHkyOA0K
PiA+Pg0KPiA+PklmIHN5c3RlbSBvcGVyYXRvciB3aWxsIGFsbG93IGxvZ2luIHZpYSBmYjEtZmIz
ICwgdGhlbiBtdXN0IA0KPiBiZSBzdGFydGVkIA0KPiA+PmFjY29yZGluZyBsb2dpbiBwcm9jZXNz
ZXMgbGlrZSBtaW5nZXR0eS4gTGluZSBmcm9tIA0KPiAvZXRjL2luaXR0YWIgPHNraXA+IA0KPiA+
PjE3OjIzNDU6cmVzcGF3bjovc2Jpbi9taW5nZXR0eSB0dHkxNyA8c2tpcD4NCj4gPj4NCj4gPj5L
ZXlib2FyZHMgYXJlIGNvbm5lY3RlZCB0byBjb25zb2xlIGF1dG9tYXRpYy4gMXN0IGNvbm5lY3Qg
DQo+IHRvIFZHQSwgMm5kIA0KPiA+PnRvIGR1bW15IDEsIDNyZCB0byBkdW1teSAyLCAuLi4NCj4g
Pj4NCj4gPj5TcGVjaWFsIGRldmljZSAvZGV2L3R0eTAgc2VlbXMgd2lsbCBub3Qgd29yayBwcm9w
ZXIuDQo+ID4+DQo+ID4+QWl2aWxzDQo+ID4+DQo+ID4+ICAgIA0KPiA+Pg0KPiA+DQo+ID4NCj4g
PiAgDQo+ID4NCj4gDQo+IA0K

Re: X11R7.0

[Aivils S. <ai...@un...>]

On Otrdiena, 31. Janv=E2ris 2006 22:19, Zephaniah E. Hull wrote:
> > Also one version before latest will not work proper if i create/delete
> > devices in the runtime. It is not official but i provide this one:
> > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2
> > This package contains xmodule, which allow load/remove X server
> > modules and xdevice, which allow create/delete X server input devices
> > at runtime. Existing input drivers are compatible with xdevice,
> > but Your not. Even xdevice never goes into main it make life easy
> > during development. You don't need server restart on new driver
> > version or on device parameter change. Fatal errors still are fatal.
> > Syntaxis like this:
> > # xmodule -l evdev
> > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1
> > You driver changes device indentifier unwarranted. You must search new
> > device
> > # xsetpointer -l
> > normal device delete uses same identifier
> > # xdevice -d e1
>
> That looks handy, however due to hotplug support my driver is going to
> cause, interesting issues.
>
> Mainly, we create new driver instances for additional devices that are
> plugged in that match the specification for current devices.
>
> Because we need the new entries to be uniquely identifiable, we append
> the phys to the name.
>
> At this time there is no way around this.
>
> Also at the moment I'm not using a modular tree, which makes using that
> a bit harder even for testing purposes.

That package didn't use compile form scratch. All what You need is X server
source for headers, runing X binary for some variables, gcc, X server resta=
rt
is necessary. I use it under my 6.8.2.

xdevice was developed keeping in mind buch of all input devices. It does
"hotplug" in large-scale without touching driver source.
Seems SIGHUP is sacred. Even aiptek tablet developers did not replay.
=46rom my point of view looks very stupid - plug new input device and then
restart X for new config.

Aivils

Re: X11R7.0

[Zephaniah E. H. <wa...@ae...>]

On Tue, Jan 31, 2006 at 11:38:39AM +0200, Aivils Stoss wrote:
> I download new version. It contains old bug: EvdevReadInput() may
> call EvdevRelSyn() on EV_SYN, but for keyboards relative stuff is 
> uninitialised - segfault. Of course driver must be capable hadle
> keys and axis events together from tablet devices, which have keys,
> absolute and relative axis and buttons too.

Ah, easily fixed, I'll post a new patch sometime today. (Though possibly
not before I run out the door.)
> 
> Also one version before latest will not work proper if i create/delete
> devices in the runtime. It is not official but i provide this one:
> http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2
> This package contains xmodule, which allow load/remove X server
> modules and xdevice, which allow create/delete X server input devices
> at runtime. Existing input drivers are compatible with xdevice,
> but Your not. Even xdevice never goes into main it make life easy
> during development. You don't need server restart on new driver
> version or on device parameter change. Fatal errors still are fatal.
> Syntaxis like this:
> # xmodule -l evdev
> # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1
> You driver changes device indentifier unwarranted. You must search new
> device
> # xsetpointer -l
> normal device delete uses same identifier
> # xdevice -d e1

That looks handy, however due to hotplug support my driver is going to
cause, interesting issues.

Mainly, we create new driver instances for additional devices that are
plugged in that match the specification for current devices.

Because we need the new entries to be uniquely identifiable, we append
the phys to the name.

At this time there is no way around this.

Also at the moment I'm not using a modular tree, which makes using that
a bit harder even for testing purposes.

Thanks.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <wa...@ae...>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

>> kinds of numbers the tobacco industry wishes it had, and Dell is very
>> very happy with the results.
>
>Do they come with a Surgeon General warning on the box?

The new ones have "Designed for Windows XP". Yes.
  -- Satya, Paul Martin, and Derek Balling in the Scary Devil Monastery.

Re: Multiple text consoles

[Zoltan B. <zb...@fr...>]

Ruben Faelens =C3=ADrta:

> In my opinion, we shouldn't try to adjust the kernel to accomplish=20
> multiple text consoles. Someone should create a VT102-compatible=20
> terminal emulation program for framebuffer. The ruby kernel has=20
> support allready for multiple dumb consoles, so these terminal=20
> emulation programs just have to be started on the right console for=20
> multiple text console support to work.


Well, the kernel already contains a mature VT100-compatible terminal=20
emulation,
look at drivers/char/vt.c. Dummy consoles can be taken over by FB console=
s
after boot in earlier Ruby versions and there have been success reports=20
on this list
using this configuration, e.g. with radeonfb with multiple adeon cards II=
RC.

>
> IMHO, true multiple console text mode is trying to push your luck. I=20
> don't think the hardware is able to pull this, afaik the linux kernel=20
> uses very simple calls to get it's text console to the screen.
> Framebuffer is the way to go for multiple text consoles, but why use=20
> framebuffer when you can use X?
>
> IIRC, some time ago somebody had the idea of creating a userspace=20
> terminal emulation program with an fbdev video output.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>
>

Re: AW: AW: Kernel Version

[Zoltan B. <zb...@fr...>]

Unger Richard =C3=ADrta:

>:)
>
>Well, I don't know about an 'offensive' - I think that might be difficul=
t.
>
>But I think a good thing to do would be to keep the linuxconsole site up=
 to date and active. I think there is interest in this project, and I thi=
nk good designs will eventually be accepted into the kernel...=20
>
>I think it is probably a matter of time, so I think a 'siege' would be b=
etter than an 'offensive' ;)
>
>What are the objections to the linuxconsole code?
>
>Richie
> =20
>

The objective (well, I would call it requirement)  was to split it up to=20
smaller pieces.
No one would look at a patch about 150K, it contains too many changes at=20
once.
Smaller logical pieces can be reviewed easily and accepted into the -mm=20
tree first
even if it breaks something.

>=20
>
> =20
>
>>-----Urspr=C3=BCngliche Nachricht-----
>>Von: Aivils Stoss [mailto:ai...@un...]=20
>>Gesendet: Dienstag, 31. J=C3=A4nner 2006 09:08
>>An: lin...@li...
>>Cc: Unger Richard; Zoltan Boszormenyi
>>Betreff: Re: AW: Kernel Version
>>
>>On Pirmdiena, 30. Janv=C4=81ris 2006 19:32, Zoltan Boszormenyi wrote:
>>   =20
>>
>>>Hi,
>>>
>>>Aivils Stoss =C3=ADrta:
>>>     =20
>>>
>>>>On Pirmdiena, 30. Janv=C4=81ris 2006 10:05, Unger Richard wrote:
>>>>=20
>>>>
>>>>       =20
>>>>
>>>>>Hi!
>>>>>
>>>>>Thanks for the tip, I should obviously have checked for tags...
>>>>>
>>>>>Is the linuxconsole stuff still under active development?
>>>>>  =20
>>>>>         =20
>>>>>
>>>>No.
>>>>=20
>>>>       =20
>>>>
>>>I still upgrade the kernel patch for every major kernel=20
>>>     =20
>>>
>>version, I am=20
>>   =20
>>
>>>on 2.6.15-ruby now.
>>>Though I always leave out fbdev as I have to update the=20
>>>     =20
>>>
>>kernel as soon=20
>>   =20
>>
>>>as possible to keep the machine running with very little downtime.
>>>     =20
>>>
>>Wow! Do You plan the offensive? I mean sending patches to=20
>>Andrew Morton and fighting against aged inhabitants.
>>
>>Aivils
>>
>>   =20
>>

Re: AW: AW: Kernel Version

[Zoltan B. <zb...@fr...>]

Unger Richard =C3=ADrta:

>Hi!
>
>Thanks for all the information!! I'll let you know how it goes (I'm sure=
 to be confused again ;)
>
>Can either of you commit your changes back to the SF site?
> =20
>

I don't have committer access rights in this project on SF.
But I can post the latest patch on the mailing list. Or a download URL.

>It seems a shame for all your hard work to be lost...
>
>And as for your English, I think I understood you very well, so I would =
have no worries there :)
>
>Regards from Vienna!
>
>Richie
>
>
>=20
>
> =20
>
>>-----Urspr=C3=BCngliche Nachricht-----
>>Von: Aivils Stoss [mailto:ai...@un...]=20
>>Gesendet: Montag, 30. J=C3=A4nner 2006 11:30
>>An: Unger Richard
>>Cc: lin...@li...
>>Betreff: Re: AW: Kernel Version
>>
>>On Pirmdiena, 30. Janv=C4=81ris 2006 10:05, Unger Richard wrote:
>>   =20
>>
>>>Hi!
>>>
>>>Thanks for the tip, I should obviously have checked for tags...
>>>
>>>Is the linuxconsole stuff still under active development?
>>>     =20
>>>
>>No.
>>
>>   =20
>>
>>>Will the redesigned console layer make it into the mainline kernel?
>>>     =20
>>>
>>Seems no.
>>1) console developing is nightmare.
>>2) 99% of testers or endusers use multiple X servers instead=20
>>of multiple text mode consoles - multiple text mode became=20
>>nuty developers trick.
>>3)I do not know how to work "terminal emulation".
>>4)I cannot write in the sane English.=20
>>
>>   =20
>>
>>>To me it seems like an obvious idea that if a multiuser system has=20
>>>multiple screens and keyboards, multiple (independant)=20
>>>     =20
>>>
>>terminals should be possible.
>>   =20
>>
>>>In fact, to me, any other situation indicates a little bit=20
>>>     =20
>>>
>>of a design=20
>>   =20
>>
>>>problem.
>>>     =20
>>>
>>Linux is so flexible. Obvious reach same result in very=20
>>different ways.
>>
>>   =20
>>
>>>Currently I'm playing with the 2.6.9-ruby kernel I compiled. Don't=20
>>>have much time as I am moving these days, but it looks like=20
>>>     =20
>>>
>>the kernel=20
>>   =20
>>
>>>boots fine and the /dev/bus/console devices are now available...
>>>
>>>I do have a few questions, documentation on this is so hard=20
>>>     =20
>>>
>>to find...
>>
>>http://www.ltn.lv/~aivils/
>>
>>   =20
>>
>>>1) Is it possible to have more than one VGA console,
>>>     =20
>>>
>>No.
>>
>>   =20
>>
>>>or is the VGA console
>>>always only bound to the primary graphics device? 2) What's=20
>>>     =20
>>>
>>the status=20
>>   =20
>>
>>>on framebuffer support? All the docs indicate framebuffer console=20
>>>isn't ready
>>>- is it worth trying out multiple fbcons?
>>>     =20
>>>
>>Each fb device (/dev/fbXX) assigned with separate console.=20
>>Each separate console may have keyboard device. Last working is 2.6.13
>>http://www.ltn.lv/~aivils/files/ruby-2.6.13-A0.diff.bz2
>>Under 2.6.13 kenel exists option
>>dumbcon=3D3:4
>>where 3 is count of dummy consoles, 4 is TTY count per single=20
>>dummy console As result VGA have tty1-tty16 dummy 1 have=20
>>tty17-tty20 dummy 2 have tty21-tty24 dummy 3 have tty25-tty28
>>
>>Probably someone load fb dev driver, which creates /dev/fb0 -=20
>>/dev/fb3, after fbcon module loading these fb devices are assigned :
>>fb0 takes over VGA - tty1-tty16
>>fb1 takes over dummy 1 - tty17-tty20
>>fb2 - tty21-tty24
>>fb3 - tty25-tty28
>>
>>If system operator will allow login via fb1-fb3 , then must=20
>>be started according login processes like mingetty. Line from=20
>>/etc/inittab <skip> 17:2345:respawn:/sbin/mingetty tty17 <skip>
>>
>>Keyboards are connected to console automatic. 1st connect to=20
>>VGA, 2nd to dummy 1, 3rd to dummy 2, ...
>>
>>Special device /dev/tty0 seems will not work proper.
>>
>>Aivils
>>
>>   =20
>>
>
>
> =20
>

Re: AW: Kernel Version

[Zoltan B. <zb...@fr...>]

Hi,

Aivils Stoss =C3=ADrta:

>On Pirmdiena, 30. Janv=C4=81ris 2006 19:32, Zoltan Boszormenyi wrote:
> =20
>
>>Hi,
>>
>>Aivils Stoss =C3=ADrta:
>>   =20
>>
>>>On Pirmdiena, 30. Janv=C4=81ris 2006 10:05, Unger Richard wrote:
>>>=20
>>>
>>>     =20
>>>
>>>>Hi!
>>>>
>>>>Thanks for the tip, I should obviously have checked for tags...
>>>>
>>>>Is the linuxconsole stuff still under active development?
>>>>  =20
>>>>       =20
>>>>
>>>No.
>>>=20
>>>     =20
>>>
>>I still upgrade the kernel patch for every major kernel version, I am o=
n
>>2.6.15-ruby now.
>>Though I always leave out fbdev as I have to update the kernel as soon
>>as possible
>>to keep the machine running with very little downtime.
>>   =20
>>
>
>Wow! Do You plan the offensive? I mean sending patches to Andrew
>Morton and fighting against aged inhabitants.
>
>Aivils
> =20
>

I am planning to but I didn't have time to really finish it and split up=20
the monster.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

AW: Multiple text consoles

[Unger R. <ric...@te...>]

Hi!=20

On the whole, I agree with you. What you say seems to make very good
sense.
Support for dumb consoles and a framebuffer terminal application would
work well.

I suppose fbcon would be a sort of 'in-kernel' version of this
framebuffer terminal app.
However, fbcon has the advantage of being able to show the system
console as well. (System console useful for boot-time interaction).
Also, on non-intel architectures there often is no VGA console (eg Mac),
only a framebuffer console. Such systems need fbcon in order to show
boot messages. So there is still justification for an in-kernel
framebuffer console layer.

Multiple VGA text consoles seems difficult (Avilis pointed out that only
one VGA device per PCI domain is allowed) - I really know too little
about it, but it seems to me that one runs into BIOS/Hardware issues
that make more than one VGA device impossible.

Basically, I think it is also difficult because the semantics for
multiple consoles are poorly defined:
-> Which console gets the boot console?
-> Which console gets which keyboard/mouse device?
Perhaps some work needs to be done to define standards for how all this
should all work.

In my eyes it isn't a matter of adjusting the kernel for multiple VGA
kernels - I think the aim should be something like the following:

0 or 1 VGA consoles
X serial consoles
Y framebuffer consoles
Z dumb consoles
(where X,Y and Z are non-negative integers)

Each of these consoles should have one or more virtual terminals
assigned.=20

If at least one console exists, one should be assigned to the system
console. This could be controlled via a kernel boot param. If none is
supplied I would say the VGA console would be a good first choice,
followed by the first framebuffer console if available.

Each of the consoles should be assigned a keyboard. Again, the
assignment could be controlled by a boot param, or perhaps, if it could
be changed without too much trouble later, there could be an initial
assignment of all keyboards to the system console at boot time, and this
would then be changed by a suitable rc-script.

In my imagination, this is how things should work :)

Regards,
Richard Unger



> In my opinion, we shouldn't try to adjust the kernel to=20
> accomplish multiple text consoles. Someone should create a=20
> VT102-compatible terminal emulation program for framebuffer.=20
> The ruby kernel has support allready for multiple dumb=20
> consoles, so these terminal emulation programs just have to=20
> be started on the right console for multiple text console=20
> support to work.
>=20
> IMHO, true multiple console text mode is trying to push your=20
> luck. I don't think the hardware is able to pull this, afaik=20
> the linux kernel uses very simple calls to get it's text=20
> console to the screen.
> Framebuffer is the way to go for multiple text consoles, but=20
> why use framebuffer when you can use X?
>=20
> IIRC, some time ago somebody had the idea of creating a=20
> userspace terminal emulation program with an fbdev video output.
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20

Multiple text consoles

[Ruben F. <par...@gm...>]

In my opinion, we shouldn't try to adjust the kernel to accomplish 
multiple text consoles. Someone should create a VT102-compatible 
terminal emulation program for framebuffer. The ruby kernel has support 
allready for multiple dumb consoles, so these terminal emulation 
programs just have to be started on the right console for multiple text 
console support to work.

IMHO, true multiple console text mode is trying to push your luck. I 
don't think the hardware is able to pull this, afaik the linux kernel 
uses very simple calls to get it's text console to the screen.
Framebuffer is the way to go for multiple text consoles, but why use 
framebuffer when you can use X?

IIRC, some time ago somebody had the idea of creating a userspace 
terminal emulation program with an fbdev video output.

Re: X11R7.0

[Aivils S. <ai...@un...>]

On Sestdiena, 28. Janv=E2ris 2006 04:11, Zephaniah E. Hull wrote:
> On Fri, Jan 27, 2006 at 09:32:20AM +0200, Aivils Stoss wrote:
> > On Ceturtdiena, 26. Janv=E2ris 2006 23:09, Peter Schrammel wrote:
> > > Yop, that seems to work. I'm useing
> > > setxkbmap de -keycodes 'xfree86+aliases(qwertz)+aliases(evdev)' -opti=
on
> > >
> > > but my up/down keys are a mess. Pressing them sometimes causes a 100%
> > > CPU load (Xorg and kwin). But this happens only on console :0 with a
> > > ps/2 keyboard and only with the extra cursor keys (not those on the
> > > numpad).
> > >
> > > On console :2 (usb) it runs smoothly, everything's fine.
> > >
> > > Tell me if I can provide you with some debug info.
> > >
> > > Sorry, avilis. I don't have a X build system installed here and (if
> > > debian helps me) never will so I can't test the patches. But thanks
> > > anyway.
> >
> > If You are not fanatic compile-from-scratch sympatizer, then You can try
> > out this one:
> > http://www.ltn.lv/~aivils/files/evdev-zeh-060127.tar.bz2
> >
> > Must have X server sources. Edit SERVER_SRC line in the Makefile
> >
> > Aivils
>
> Thanks a ton for putting that together.
>
> However there's been a slight bug fix patch update which helps
> compiling with some compilers.
>
> If you'd like I can generate a diff between that version and current?

I download new version. It contains old bug: EvdevReadInput() may
call EvdevRelSyn() on EV_SYN, but for keyboards relative stuff is=20
uninitialised - segfault. Of course driver must be capable hadle
keys and axis events together from tablet devices, which have keys,
absolute and relative axis and buttons too.

Also one version before latest will not work proper if i create/delete
devices in the runtime. It is not official but i provide this one:
http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2
This package contains xmodule, which allow load/remove X server
modules and xdevice, which allow create/delete X server input devices
at runtime. Existing input drivers are compatible with xdevice,
but Your not. Even xdevice never goes into main it make life easy
during development. You don't need server restart on new driver
version or on device parameter change. Fatal errors still are fatal.
Syntaxis like this:
# xmodule -l evdev
# xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1
You driver changes device indentifier unwarranted. You must search new
device
# xsetpointer -l
normal device delete uses same identifier
# xdevice -d e1

Aivils

AW: AW: Kernel Version

[Unger R. <ric...@te...>]

OikNCg0KV2VsbCwgSSBkb24ndCBrbm93IGFib3V0IGFuICdvZmZlbnNpdmUnIC0gSSB0aGluayB0
aGF0IG1pZ2h0IGJlIGRpZmZpY3VsdC4NCg0KQnV0IEkgdGhpbmsgYSBnb29kIHRoaW5nIHRvIGRv
IHdvdWxkIGJlIHRvIGtlZXAgdGhlIGxpbnV4Y29uc29sZSBzaXRlIHVwIHRvIGRhdGUgYW5kIGFj
dGl2ZS4gSSB0aGluayB0aGVyZSBpcyBpbnRlcmVzdCBpbiB0aGlzIHByb2plY3QsIGFuZCBJIHRo
aW5rIGdvb2QgZGVzaWducyB3aWxsIGV2ZW50dWFsbHkgYmUgYWNjZXB0ZWQgaW50byB0aGUga2Vy
bmVsLi4uIA0KDQpJIHRoaW5rIGl0IGlzIHByb2JhYmx5IGEgbWF0dGVyIG9mIHRpbWUsIHNvIEkg
dGhpbmsgYSAnc2llZ2UnIHdvdWxkIGJlIGJldHRlciB0aGFuIGFuICdvZmZlbnNpdmUnIDspDQoN
CldoYXQgYXJlIHRoZSBvYmplY3Rpb25zIHRvIHRoZSBsaW51eGNvbnNvbGUgY29kZT8NCg0KUmlj
aGllDQogDQoNCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEFp
dmlscyBTdG9zcyBbbWFpbHRvOmFpdmlsc0B1bmliYW5rYS5sdl0gDQo+IEdlc2VuZGV0OiBEaWVu
c3RhZywgMzEuIErDpG5uZXIgMjAwNiAwOTowOA0KPiBBbjogbGludXhjb25zb2xlLWRldkBsaXN0
cy5zb3VyY2Vmb3JnZS5uZXQNCj4gQ2M6IFVuZ2VyIFJpY2hhcmQ7IFpvbHRhbiBCb3N6b3JtZW55
aQ0KPiBCZXRyZWZmOiBSZTogQVc6IEtlcm5lbCBWZXJzaW9uDQo+IA0KPiBPbiBQaXJtZGllbmEs
IDMwLiBKYW52xIFyaXMgMjAwNiAxOTozMiwgWm9sdGFuIEJvc3pvcm1lbnlpIHdyb3RlOg0KPiA+
IEhpLA0KPiA+DQo+ID4gQWl2aWxzIFN0b3NzIMOtcnRhOg0KPiA+ID5PbiBQaXJtZGllbmEsIDMw
LiBKYW52xIFyaXMgMjAwNiAxMDowNSwgVW5nZXIgUmljaGFyZCB3cm90ZToNCj4gPiA+IMKgDQo+
ID4gPg0KPiA+ID4+SGkhDQo+ID4gPj4NCj4gPiA+PlRoYW5rcyBmb3IgdGhlIHRpcCwgSSBzaG91
bGQgb2J2aW91c2x5IGhhdmUgY2hlY2tlZCBmb3IgdGFncy4uLg0KPiA+ID4+DQo+ID4gPj5JcyB0
aGUgbGludXhjb25zb2xlIHN0dWZmIHN0aWxsIHVuZGVyIGFjdGl2ZSBkZXZlbG9wbWVudD8NCj4g
PiA+PiDCoCDCoA0KPiA+ID4NCj4gPiA+Tm8uDQo+ID4gPiDCoA0KPiA+DQo+ID4gSSBzdGlsbCB1
cGdyYWRlIHRoZSBrZXJuZWwgcGF0Y2ggZm9yIGV2ZXJ5IG1ham9yIGtlcm5lbCANCj4gdmVyc2lv
biwgSSBhbSANCj4gPiBvbiAyLjYuMTUtcnVieSBub3cuDQo+ID4gVGhvdWdoIEkgYWx3YXlzIGxl
YXZlIG91dCBmYmRldiBhcyBJIGhhdmUgdG8gdXBkYXRlIHRoZSANCj4ga2VybmVsIGFzIHNvb24g
DQo+ID4gYXMgcG9zc2libGUgdG8ga2VlcCB0aGUgbWFjaGluZSBydW5uaW5nIHdpdGggdmVyeSBs
aXR0bGUgZG93bnRpbWUuDQo+IA0KPiBXb3chIERvIFlvdSBwbGFuIHRoZSBvZmZlbnNpdmU/IEkg
bWVhbiBzZW5kaW5nIHBhdGNoZXMgdG8gDQo+IEFuZHJldyBNb3J0b24gYW5kIGZpZ2h0aW5nIGFn
YWluc3QgYWdlZCBpbmhhYml0YW50cy4NCj4gDQo+IEFpdmlscw0KPiANCg==

AW: AW: Kernel Version

[Unger R. <ric...@te...>]

Hi!

Thanks for all the information!! I'll let you know how it goes (I'm sure =
to be confused again ;)

Can either of you commit your changes back to the SF site?
It seems a shame for all your hard work to be lost...

And as for your English, I think I understood you very well, so I would =
have no worries there :)

Regards from Vienna!

Richie


=20

> -----Urspr=FCngliche Nachricht-----
> Von: Aivils Stoss [mailto:ai...@un...]=20
> Gesendet: Montag, 30. J=E4nner 2006 11:30
> An: Unger Richard
> Cc: lin...@li...
> Betreff: Re: AW: Kernel Version
>=20
> On Pirmdiena, 30. Janv=E2ris 2006 10:05, Unger Richard wrote:
> > Hi!
> >
> > Thanks for the tip, I should obviously have checked for tags...
> >
> > Is the linuxconsole stuff still under active development?
>=20
> No.
>=20
> > Will the redesigned console layer make it into the mainline kernel?
>=20
> Seems no.
> 1) console developing is nightmare.
> 2) 99% of testers or endusers use multiple X servers instead=20
> of multiple text mode consoles - multiple text mode became=20
> nuty developers trick.
> 3)I do not know how to work "terminal emulation".
> 4)I cannot write in the sane English.=20
>=20
> > To me it seems like an obvious idea that if a multiuser system has=20
> > multiple screens and keyboards, multiple (independant)=20
> terminals should be possible.
> > In fact, to me, any other situation indicates a little bit=20
> of a design=20
> > problem.
>=20
> Linux is so flexible. Obvious reach same result in very=20
> different ways.
>=20
> > Currently I'm playing with the 2.6.9-ruby kernel I compiled. Don't=20
> > have much time as I am moving these days, but it looks like=20
> the kernel=20
> > boots fine and the /dev/bus/console devices are now available...
> >
> > I do have a few questions, documentation on this is so hard=20
> to find...
>=20
> http://www.ltn.lv/~aivils/
>=20
> > 1) Is it possible to have more than one VGA console,
>=20
> No.
>=20
> > or is the VGA console
> > always only bound to the primary graphics device? 2) What's=20
> the status=20
> > on framebuffer support? All the docs indicate framebuffer console=20
> > isn't ready
> > - is it worth trying out multiple fbcons?
>=20
> Each fb device (/dev/fbXX) assigned with separate console.=20
> Each separate console may have keyboard device. Last working is 2.6.13
> http://www.ltn.lv/~aivils/files/ruby-2.6.13-A0.diff.bz2
> Under 2.6.13 kenel exists option
> dumbcon=3D3:4
> where 3 is count of dummy consoles, 4 is TTY count per single=20
> dummy console As result VGA have tty1-tty16 dummy 1 have=20
> tty17-tty20 dummy 2 have tty21-tty24 dummy 3 have tty25-tty28
>=20
> Probably someone load fb dev driver, which creates /dev/fb0 -=20
> /dev/fb3, after fbcon module loading these fb devices are assigned :
> fb0 takes over VGA - tty1-tty16
> fb1 takes over dummy 1 - tty17-tty20
> fb2 - tty21-tty24
> fb3 - tty25-tty28
>=20
> If system operator will allow login via fb1-fb3 , then must=20
> be started according login processes like mingetty. Line from=20
> /etc/inittab <skip> 17:2345:respawn:/sbin/mingetty tty17 <skip>
>=20
> Keyboards are connected to console automatic. 1st connect to=20
> VGA, 2nd to dummy 1, 3rd to dummy 2, ...
>=20
> Special device /dev/tty0 seems will not work proper.
>=20
> Aivils
>=20

Re: AW: Kernel Version

[Aivils S. <ai...@un...>]

On Pirmdiena, 30. Janv=C4=81ris 2006 19:32, Zoltan Boszormenyi wrote:
> Hi,
>
> Aivils Stoss =C3=ADrta:
> >On Pirmdiena, 30. Janv=C4=81ris 2006 10:05, Unger Richard wrote:
> > =C2=A0
> >
> >>Hi!
> >>
> >>Thanks for the tip, I should obviously have checked for tags...
> >>
> >>Is the linuxconsole stuff still under active development?
> >> =C2=A0 =C2=A0
> >
> >No.
> > =C2=A0
>
> I still upgrade the kernel patch for every major kernel version, I am on
> 2.6.15-ruby now.
> Though I always leave out fbdev as I have to update the kernel as soon
> as possible
> to keep the machine running with very little downtime.

Wow! Do You plan the offensive? I mean sending patches to Andrew
Morton and fighting against aged inhabitants.

Aivils

Re: AW: Kernel Version

[Zoltan B. <zb...@fr...>]

Hi,

Aivils Stoss =C3=ADrta:

>On Pirmdiena, 30. Janv=C4=81ris 2006 10:05, Unger Richard wrote:
> =20
>
>>Hi!
>>
>>Thanks for the tip, I should obviously have checked for tags...
>>
>>Is the linuxconsole stuff still under active development?
>>   =20
>>
>
>No.
> =20
>

I still upgrade the kernel patch for every major kernel version, I am on=20
2.6.15-ruby now.
Though I always leave out fbdev as I have to update the kernel as soon=20
as possible
to keep the machine running with very little downtime.

>>Will the redesigned console layer make it into the mainline kernel?
>>   =20
>>
>
>Seems no.
>1) console developing is nightmare.
> =20
>
... and almost everyone updates it in mainline.

>2) 99% of testers or endusers use multiple X servers instead of multiple=
 text=20
>mode consoles - multiple text mode became nuty developers trick.
> =20
>

But the kernel developers and embedded system users may find it useful, t=
oo.

>3)I do not know how to work "terminal emulation".
>4)I cannot write in the sane English.=20
> =20
>
That's not a real problem. :-)

>>To me it seems like an obvious idea that if a multiuser system has mult=
iple
>>screens and keyboards, multiple (independant) terminals should be possi=
ble.
>>In fact, to me, any other situation indicates a little bit of a design
>>problem.
>>   =20
>>
>
>Linux is so flexible. Obvious reach same result in very different ways.
>
> =20
>
>>Currently I'm playing with the 2.6.9-ruby kernel I compiled. Don't have
>>much time as I am moving these days, but it looks like the kernel boots
>>fine and the /dev/bus/console devices are now available...
>>
>>I do have a few questions, documentation on this is so hard to find...
>>   =20
>>
>
>http://www.ltn.lv/~aivils/
>
> =20
>
>>1) Is it possible to have more than one VGA console,
>>   =20
>>
>
>No.
> =20
>

But development is under way. Every PCI domain can have only one
active VGA device in any given moment. By "active" I mean the device
decodes the VGA address lines and responds to reads and writes.
Hopefully VGA cards keep the display active while their VGA addressing
mode are deactivated. An in-kernel VGA arbiter is developed by (I think)
Dave Arlie. You can find him on the dri...@li...
and xo...@li... mailing lists.

>>or is the VGA console=20
>>always only bound to the primary graphics device? 2) What's the status =
on
>>framebuffer support? All the docs indicate framebuffer console isn't re=
ady
>>- is it worth trying out multiple fbcons?
>>   =20
>>
>
>Each fb device (/dev/fbXX) assigned with separate console. Each separate
>console may have keyboard device. Last working is 2.6.13
>http://www.ltn.lv/~aivils/files/ruby-2.6.13-A0.diff.bz2
>Under 2.6.13 kenel exists option
>dumbcon=3D3:4
>where 3 is count of dummy consoles, 4 is TTY count per single dummy cons=
ole
>As result
>VGA have tty1-tty16
>dummy 1 have tty17-tty20
>dummy 2 have tty21-tty24
>dummy 3 have tty25-tty28
>
>Probably someone load fb dev driver, which creates /dev/fb0 - /dev/fb3,
>after fbcon module loading these fb devices are assigned :
>fb0 takes over VGA - tty1-tty16
>fb1 takes over dummy 1 - tty17-tty20
>fb2 - tty21-tty24
>fb3 - tty25-tty28
>
>If system operator will allow login via fb1-fb3 , then must be started
>according login processes like mingetty. Line from /etc/inittab
><skip>
>17:2345:respawn:/sbin/mingetty tty17
><skip>
>
>Keyboards are connected to console automatic. 1st connect to VGA,
>2nd to dummy 1, 3rd to dummy 2, ...
>
>Special device /dev/tty0 seems will not work proper.
>
>Aivils
> =20
>

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Re: AW: Kernel Version

[Aivils S. <ai...@un...>]

On Pirmdiena, 30. Janv=E2ris 2006 10:05, Unger Richard wrote:
> Hi!
>
> Thanks for the tip, I should obviously have checked for tags...
>
> Is the linuxconsole stuff still under active development?

No.

> Will the redesigned console layer make it into the mainline kernel?

Seems no.
1) console developing is nightmare.
2) 99% of testers or endusers use multiple X servers instead of multiple te=
xt=20
mode consoles - multiple text mode became nuty developers trick.
3)I do not know how to work "terminal emulation".
4)I cannot write in the sane English.=20

> To me it seems like an obvious idea that if a multiuser system has multip=
le
> screens and keyboards, multiple (independant) terminals should be possibl=
e.
> In fact, to me, any other situation indicates a little bit of a design
> problem.

Linux is so flexible. Obvious reach same result in very different ways.

> Currently I'm playing with the 2.6.9-ruby kernel I compiled. Don't have
> much time as I am moving these days, but it looks like the kernel boots
> fine and the /dev/bus/console devices are now available...
>
> I do have a few questions, documentation on this is so hard to find...

http://www.ltn.lv/~aivils/

> 1) Is it possible to have more than one VGA console,

No.

> or is the VGA console=20
> always only bound to the primary graphics device? 2) What's the status on
> framebuffer support? All the docs indicate framebuffer console isn't ready
> - is it worth trying out multiple fbcons?

Each fb device (/dev/fbXX) assigned with separate console. Each separate
console may have keyboard device. Last working is 2.6.13
http://www.ltn.lv/~aivils/files/ruby-2.6.13-A0.diff.bz2
Under 2.6.13 kenel exists option
dumbcon=3D3:4
where 3 is count of dummy consoles, 4 is TTY count per single dummy console
As result
VGA have tty1-tty16
dummy 1 have tty17-tty20
dummy 2 have tty21-tty24
dummy 3 have tty25-tty28

Probably someone load fb dev driver, which creates /dev/fb0 - /dev/fb3,
after fbcon module loading these fb devices are assigned :
fb0 takes over VGA - tty1-tty16
fb1 takes over dummy 1 - tty17-tty20
fb2 - tty21-tty24
fb3 - tty25-tty28

If system operator will allow login via fb1-fb3 , then must be started
according login processes like mingetty. Line from /etc/inittab
<skip>
17:2345:respawn:/sbin/mingetty tty17
<skip>

Keyboards are connected to console automatic. 1st connect to VGA,
2nd to dummy 1, 3rd to dummy 2, ...

Special device /dev/tty0 seems will not work proper.

Aivils