Re: [oi-dev] Toward a SPARC distro of OI

2019-06-17 Thread Till Wegmüller
Hi Gary

Thank you so much for this Work. I don't personaly use sparc but ir is
good to see people doing this kinds of projects.

Do you know about Agnar's Project to get OI building on SPARC? I can't
remember if I ever pointed you towards him and his OI on Sparc work. His
angle was to jump from an existing OI distro to current packages and
later looking in V9OS.

Greetings
Till

On 17.06.19 13:26, Aurélien Larcher wrote:
> 
> 
> On Mon, Jun 17, 2019 at 11:59 AM Gary Mills  > wrote:
> 
> I'm part way through this long project now.  I began with v9os
> installed on a Sun T2000.  v9os is a SPARC distribution that uses IPS
> packages.  I've been building IPS packages from oi-userland source.
> This process has gotten easier now that all the build tools I need are
> in IPS packages.  I've been replacing v9os packages with oi-userland
> packages.  My goal is to replace all of them, and finally to produce a
> text ISO and package repository for SPARC that's entirely based on
> oi-userland.
> 
> So far, I've built and packaged versions 5, 6, and 7 of the gcc
> compiler.  The commands for IPS packages are all packaged for python
> 2.7.  My system now has 106 packages installed from oi-userland,
> versus 343 packages from v9os.  Most of the oi-userland products
> required very few or no changes to build and package for SPARC.
> 
> For perl, I've removed the 5.16.1 version from v9os and installed
> versions 5.22 and 5.24 from oi-userland.  Likewise, for python, I've
> removed 2.6 and installed 2.7 and 3.4.  Perl libraries are all
> packaged for 5.22.  Python libraries are all packaged for 2.7.
> 
> I'm submitting this message to the mailing list mostly as a progress
> report.  I would, of course, appreciate a bit of help with this
> project.
> 
> 
> Congratulations Gary this is great :)
> If we get to the point that we can setup a build machine this would
> secure your work.
> Kind regards
> 
> Aurélien
> 
>  
> 
> 
> 
> -- 
> -Gary Mills-            -refurb-                -Winnipeg, Manitoba,
> Canada-
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org 
> https://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
> 

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] Toward a SPARC distro of OI

2019-06-17 Thread Aurélien Larcher
On Mon, Jun 17, 2019 at 11:59 AM Gary Mills  wrote:

> I'm part way through this long project now.  I began with v9os
> installed on a Sun T2000.  v9os is a SPARC distribution that uses IPS
> packages.  I've been building IPS packages from oi-userland source.
> This process has gotten easier now that all the build tools I need are
> in IPS packages.  I've been replacing v9os packages with oi-userland
> packages.  My goal is to replace all of them, and finally to produce a
> text ISO and package repository for SPARC that's entirely based on
> oi-userland.
>
> So far, I've built and packaged versions 5, 6, and 7 of the gcc
> compiler.  The commands for IPS packages are all packaged for python
> 2.7.  My system now has 106 packages installed from oi-userland,
> versus 343 packages from v9os.  Most of the oi-userland products
> required very few or no changes to build and package for SPARC.
>
> For perl, I've removed the 5.16.1 version from v9os and installed
> versions 5.22 and 5.24 from oi-userland.  Likewise, for python, I've
> removed 2.6 and installed 2.7 and 3.4.  Perl libraries are all
> packaged for 5.22.  Python libraries are all packaged for 2.7.
>
> I'm submitting this message to the mailing list mostly as a progress
> report.  I would, of course, appreciate a bit of help with this
> project.
>

Congratulations Gary this is great :)
If we get to the point that we can setup a build machine this would secure
your work.
Kind regards

Aurélien



>
>
> --
> -Gary Mills--refurb--Winnipeg, Manitoba,
> Canada-
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
>


-- 
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread Jim Klimov
On June 11, 2019 9:29:23 PM UTC, ran...@sibernet.com wrote:
>
>
>On Tue, 11 Jun 2019, Toomas Soome via illumos-developer wrote:
>
>> I’d say, anything to encourage people to try, use and join to develop
>[illumos] is very welcome. Better laptop support will definitely be
>> bonus.
>
> Betting better graphics support would be higher on the list (yea, the 
>other 'dropped' project).
>
>   Cheers!
>
> Randy
>
>> 
>> Sent from my iPhone
>> 
>> On 11 Jun 2019, at 22:58, Garrett D'Amore  wrote:
>> 
>> My gut instinct is that this isn’t that interesting – most everyone
>is running illumos in either VMs, or in datacenter
>> applications where suspend/resume has little if any applicability.
>> 
>> While the work itself is probably interesting, and it may enable new
>applications for illumos, the concern I’d have would be
>> detraction from other more pressing work, without any clear use cases
>for it.
>> 
>> That said, if someone (you?) wanted to spend cycles on this for
>personal satisfaction, I hardly see any reason to discourage it,
>> and I’m fairly certain if the risks of the new code being introduced
>are small (or well managed by sufficient testing for
>> example), I can’t see any other reason we would reject a suitably
>formed RTI.
>> 
>> Sent from Mail for Windows 10
>> 
>> From: ran...@sibernet.com
>> Sent: Tuesday, June 11, 2019 11:10 AM
>> To: oi-dev@openindiana.org; develo...@lists.illumos.org
>> Subject: [developer] suspend/resume in Illumos
>> 
>> I have a question for developers here:
>> 
>>     How important is suspend/resume for OI/Illumos (including S4)?
>> 
>> One of the incomplete projects left behind was S4 (lack of need, and
>a
>> 
>> hard to identify bug stifled it's integration).  It is non-trivial,
>and
>> 
>> needs updated s/r core code (added configuration and significant
>> 
>> restructuring, as well as likely assistance from developers
>knowlegable in
>> 
>> other Illumos internals), but if this is an uninteresting feature, it
>is
>> 
>> likey not worth the effort (recent bugs suggest that few if anyone
>use
>> 
>> it); however, it wouldn't be too hard to resurect (though would still
>take
>> 
>> several months of work).
>> 
>>    Cheers!
>> 
>>      Randy
>> 
>> illumos / illumos-developer / see discussions + participants +
>delivery options Permalink
>> 
>--
>illumos: illumos-developer
>Permalink:
>https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-Ma4a7672659b46c13f040eb9e
>Delivery options:
>https://illumos.topicbox.com/groups/developer/subscription

For my 2c, I have to use OI in a VM rather than baremetal on my laptop (would 
love to some day; it is part of my daily desktop for years now) because of a 
mix of these issues. While graphics and wifi drivers might be worked around by 
careful choice of hardware for a new rig, effective lack of sleep/hibernate is 
a big problem.

My sessions of desktop OS uptime tend to be weeks and months long, many apps 
and tabs open... so rebooting every morning is not quite an option.

Jim

--
Typos courtesy of K-9 Mail on my Android

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread Joshua M. Clulow
On Tue, 11 Jun 2019 at 14:29,  wrote:
> On Tue, 11 Jun 2019, Toomas Soome via illumos-developer wrote:
> > I’d say, anything to encourage people to try, use and join to develop 
> > [illumos] is very welcome. Better laptop support will definitely be
> > bonus.
>
>Betting better graphics support would be higher on the list (yea, the
> other 'dropped' project).

I think there are a fair few people who would appreciate some serious
elbow grease being applied to the graphics bits!


Cheers.

-- 
Joshua M. Clulow
Engineer @ Joyent
http://blog.sysmgr.org

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread randyf



On Tue, 11 Jun 2019, Toomas Soome via illumos-developer wrote:


I’d say, anything to encourage people to try, use and join to develop [illumos] 
is very welcome. Better laptop support will definitely be
bonus.


  Betting better graphics support would be higher on the list (yea, the 
other 'dropped' project).


  Cheers!

 Randy



Sent from my iPhone

On 11 Jun 2019, at 22:58, Garrett D'Amore  wrote:

  My gut instinct is that this isn’t that interesting – most everyone is 
running illumos in either VMs, or in datacenter
  applications where suspend/resume has little if any applicability.

   

  While the work itself is probably interesting, and it may enable new 
applications for illumos, the concern I’d have would be
  detraction from other more pressing work, without any clear use cases for 
it.

   

  That said, if someone (you?) wanted to spend cycles on this for personal 
satisfaction, I hardly see any reason to discourage it,
  and I’m fairly certain if the risks of the new code being introduced are 
small (or well managed by sufficient testing for
  example), I can’t see any other reason we would reject a suitably formed 
RTI.

   

  Sent from Mail for Windows 10

   

  From: ran...@sibernet.com
  Sent: Tuesday, June 11, 2019 11:10 AM
  To: oi-dev@openindiana.org; develo...@lists.illumos.org
  Subject: [developer] suspend/resume in Illumos

 

 

 

I have a question for developers here:

 

    How important is suspend/resume for OI/Illumos (including S4)?

 

 

One of the incomplete projects left behind was S4 (lack of need, and a

hard to identify bug stifled it's integration).  It is non-trivial, and

needs updated s/r core code (added configuration and significant

restructuring, as well as likely assistance from developers knowlegable in

other Illumos internals), but if this is an uninteresting feature, it is

likey not worth the effort (recent bugs suggest that few if anyone use

it); however, it wouldn't be too hard to resurect (though would still take

several months of work).

 

 

   Cheers!

 

     Randy

 

--

illumos: illumos-developer

Permalink: 
https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f

Delivery options: https://illumos.topicbox.com/groups/developer/subscription

 

illumos / illumos-developer / see discussions + participants + delivery options 
Permalink

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread randyf



On Tue, 11 Jun 2019, Garrett D'Amore wrote:



My gut instinct is that this isn’t that interesting – most everyone is running 
illumos in either VMs, or in datacenter applications where
suspend/resume has little if any applicability.

 

While the work itself is probably interesting, and it may enable new 
applications for illumos, the concern I’d have would be detraction from
other more pressing work, without any clear use cases for it.



  I should point out that s/r isn't just for laptop bare-metal.  It allows 
for a running instance of an OS to be frozen in an orderly manner (rather 
than a VM just pausing a guest, the guest suspends first).  S4 opens a 
different world of allowing said image to be more easily migrated, or 
(since it has roots in CPR) opens quick-boot images (imagine getting an 
OS fully booted in under 10 seconds).



 

That said, if someone (you?) wanted to spend cycles on this for personal 
satisfaction, I hardly see any reason to discourage it, and I’m
fairly certain if the risks of the new code being introduced are small (or well 
managed by sufficient testing for example), I can’t see any
other reason we would reject a suitably formed RTI.



  Doubt I'll fully drop it, but without sufficient interest, it's is 
unlikely I'll give it much priority (certainly, my other 'dropped' project 
should have a higer priority).


  Cheers!

 Randy


 

Sent from Mail for Windows 10

 

From: ran...@sibernet.com
Sent: Tuesday, June 11, 2019 11:10 AM
To: oi-dev@openindiana.org; develo...@lists.illumos.org
Subject: [developer] suspend/resume in Illumos

 

 

 

I have a question for developers here:

 

    How important is suspend/resume for OI/Illumos (including S4)?

 

 

One of the incomplete projects left behind was S4 (lack of need, and a

hard to identify bug stifled it's integration).  It is non-trivial, and

needs updated s/r core code (added configuration and significant

restructuring, as well as likely assistance from developers knowlegable in

other Illumos internals), but if this is an uninteresting feature, it is

likey not worth the effort (recent bugs suggest that few if anyone use

it); however, it wouldn't be too hard to resurect (though would still take

several months of work).

 

 

   Cheers!

 

     Randy

 

--

illumos: illumos-developer

Permalink: 
https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f

Delivery options: https://illumos.topicbox.com/groups/developer/subscription

 

illumos / illumos-developer / see discussions + participants + delivery options 
Permalink

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread Garrett D'Amore
My gut instinct is that this isn’t that interesting – most everyone is running 
illumos in either VMs, or in datacenter applications where suspend/resume has 
little if any applicability.

While the work itself is probably interesting, and it may enable new 
applications for illumos, the concern I’d have would be detraction from other 
more pressing work, without any clear use cases for it.

That said, if someone (you?) wanted to spend cycles on this for personal 
satisfaction, I hardly see any reason to discourage it, and I’m fairly certain 
if the risks of the new code being introduced are small (or well managed by 
sufficient testing for example), I can’t see any other reason we would reject a 
suitably formed RTI.

Sent from Mail for Windows 10

From: ran...@sibernet.com
Sent: Tuesday, June 11, 2019 11:10 AM
To: oi-dev@openindiana.org; develo...@lists.illumos.org
Subject: [developer] suspend/resume in Illumos



I have a question for developers here:

How important is suspend/resume for OI/Illumos (including S4)?


One of the incomplete projects left behind was S4 (lack of need, and a 
hard to identify bug stifled it's integration).  It is non-trivial, and 
needs updated s/r core code (added configuration and significant 
restructuring, as well as likely assistance from developers knowlegable in 
other Illumos internals), but if this is an uninteresting feature, it is 
likey not worth the effort (recent bugs suggest that few if anyone use 
it); however, it wouldn't be too hard to resurect (though would still take 
several months of work).


   Cheers!

 Randy

--
illumos: illumos-developer
Permalink: 
https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f
Delivery options: https://illumos.topicbox.com/groups/developer/subscription

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] [developer] suspend/resume in Illumos

2019-06-17 Thread Toomas Soome via oi-dev
I’d say, anything to encourage people to try, use and join to develop [illumos] 
is very welcome. Better laptop support will definitely be bonus.

Sent from my iPhone

> On 11 Jun 2019, at 22:58, Garrett D'Amore  wrote:
> 
> My gut instinct is that this isn’t that interesting – most everyone is 
> running illumos in either VMs, or in datacenter applications where 
> suspend/resume has little if any applicability.
>  
> While the work itself is probably interesting, and it may enable new 
> applications for illumos, the concern I’d have would be detraction from other 
> more pressing work, without any clear use cases for it.
>  
> That said, if someone (you?) wanted to spend cycles on this for personal 
> satisfaction, I hardly see any reason to discourage it, and I’m fairly 
> certain if the risks of the new code being introduced are small (or well 
> managed by sufficient testing for example), I can’t see any other reason we 
> would reject a suitably formed RTI.
>  
> Sent from Mail for Windows 10
>  
> From: ran...@sibernet.com
> Sent: Tuesday, June 11, 2019 11:10 AM
> To: oi-dev@openindiana.org; develo...@lists.illumos.org
> Subject: [developer] suspend/resume in Illumos
>  
>  
>  
> I have a question for developers here:
>  
> How important is suspend/resume for OI/Illumos (including S4)?
>  
>  
> One of the incomplete projects left behind was S4 (lack of need, and a
> hard to identify bug stifled it's integration).  It is non-trivial, and
> needs updated s/r core code (added configuration and significant
> restructuring, as well as likely assistance from developers knowlegable in
> other Illumos internals), but if this is an uninteresting feature, it is
> likey not worth the effort (recent bugs suggest that few if anyone use
> it); however, it wouldn't be too hard to resurect (though would still take
> several months of work).
>  
>  
>Cheers!
>  
>  Randy
>  
> --
> illumos: illumos-developer
> Permalink: 
> https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f
> Delivery options: https://illumos.topicbox.com/groups/developer/subscription
>  
> illumos / illumos-developer / see discussions + participants + delivery 
> options Permalink
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


[oi-dev] Toward a SPARC distro of OI

2019-06-17 Thread Gary Mills
I'm part way through this long project now.  I began with v9os
installed on a Sun T2000.  v9os is a SPARC distribution that uses IPS
packages.  I've been building IPS packages from oi-userland source.
This process has gotten easier now that all the build tools I need are
in IPS packages.  I've been replacing v9os packages with oi-userland
packages.  My goal is to replace all of them, and finally to produce a
text ISO and package repository for SPARC that's entirely based on
oi-userland.

So far, I've built and packaged versions 5, 6, and 7 of the gcc
compiler.  The commands for IPS packages are all packaged for python
2.7.  My system now has 106 packages installed from oi-userland,
versus 343 packages from v9os.  Most of the oi-userland products
required very few or no changes to build and package for SPARC.

For perl, I've removed the 5.16.1 version from v9os and installed
versions 5.22 and 5.24 from oi-userland.  Likewise, for python, I've
removed 2.6 and installed 2.7 and 3.4.  Perl libraries are all
packaged for 5.22.  Python libraries are all packaged for 2.7.

I'm submitting this message to the mailing list mostly as a progress
report.  I would, of course, appreciate a bit of help with this
project.


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


[oi-dev] suspend/resume in Illumos

2019-06-17 Thread randyf




I have a question for developers here:

   How important is suspend/resume for OI/Illumos (including S4)?


One of the incomplete projects left behind was S4 (lack of need, and a 
hard to identify bug stifled it's integration).  It is non-trivial, and 
needs updated s/r core code (added configuration and significant 
restructuring, as well as likely assistance from developers knowlegable in 
other Illumos internals), but if this is an uninteresting feature, it is 
likey not worth the effort (recent bugs suggest that few if anyone use 
it); however, it wouldn't be too hard to resurect (though would still take 
several months of work).



  Cheers!

 Randy

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] Openindiana on Laptop: touchpad not working

2019-06-17 Thread Carsten Grzemba via oi-dev


On 03.06.19 16:44, "Carsten Grzemba"   wrote: 
> 
> 
> 
> On 23.05.19 08:34, Carsten Grzemba via oi-dev   
> wrote: 
> > 
> > I compared the Xorg log:
> > 
> > in the working log the mouse driver is loaded on PS/s mouse on /dev/mouse:
> > 
> > [ 38.008] (II) LoadModule: "mouse"
> > [ 38.008] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so
> > [ 38.012] (II) Module mouse: vendor="X.Org Foundation"
> > [ 38.012] compiled for 1.19.5, module version = 1.9.2
> > [ 38.012] Module class: X.Org XInput Driver
> > [ 38.012] ABI class: X.Org XInput driver, version 24.1
> > [ 38.012] (II) Using input driver 'mouse' for 'PS/2 Port for PS/2-style 
> > Mice'
> > [ 38.012] (**) PS/2 Port for PS/2-style Mice: always reports core events
> > [ 38.012] (**) Option "Device" "/dev/mouse"
> > [ 38.012] (II) PS/2 Port for PS/2-style Mice: Setting Device option to 
> > "/dev/mouse"
> > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Protocol: "VUID"
> > [ 38.014] (**) PS/2 Port for PS/2-style Mice: always reports core events
> > [ 38.014] (**) Option "Device" "/dev/mouse"
> > [ 38.014] (==) PS/2 Port for PS/2-style Mice: Emulate3Buttons, 
> > Emulate3Timeout: 50
> > [ 38.014] (**) PS/2 Port for PS/2-style Mice: ZAxisMapping: buttons 4 and 5
> > [ 38.014] (**) PS/2 Port for PS/2-style Mice: Buttons: 9
> > [ 38.014] (**) Option "config_info" 
> > "hal:/org/freedesktop/Hal/devices/pci_0_0/isa_1f/i8042_1_60/mouse_1_0_logicaldev_input"
> > [ 38.014] (II) XINPUT: Adding extended input device "PS/2 Port for 
> > PS/2-style Mice" (type: MOUSE, id 6)
> > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) keeping acceleration 
> > scheme 1
> > [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration profile 0
> > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration factor: 
> > 2.000
> > [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration 
> > threshold: 4
> > 
> > and the not working on the generic USB device /dev/usb/hid1:
> > 
> > [ 523.036] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so
> > [ 523.036] (II) Module mouse: vendor="X.Org Foundation"
> > [ 523.036] compiled for 1.19.5, module version = 1.9.2
> > [ 523.036] Module class: X.Org XInput Driver
> > [ 523.037] ABI class: X.Org XInput driver, version 24.1
> > [ 523.037] (II) Using input driver 'mouse' for 'mouse'
> > [ 523.037] (**) mouse: always reports core events
> > [ 523.037] (**) Option "Protocol" "VUID"
> > [ 523.037] (**) Option "Device" "/dev/usb/hid1"
> > [ 523.037] (**) Option "StreamsModule" "usbms"
> > [ 523.039] (**) mouse: Protocol: "VUID"
> > [ 523.039] (**) mouse: always reports core events
> > [ 523.039] (==) mouse: Emulate3Buttons, Emulate3Timeout: 50
> > [ 523.039] (**) mouse: ZAxisMapping: buttons 4 and 5
> > [ 523.039] (**) mouse: Buttons: 9
> > [ 523.039] (**) Option "config_info" 
> > "hal:/org/freedesktop/Hal/devices/pci_0_0/pci1025_1019_14/device_4/mouse_1_if1_4_logicaldev_input"
> > [ 523.039] (II) XINPUT: Adding extended input device "mouse" (type: MOUSE, 
> > id 6)
> > [ 523.039] (**) mouse: (accel) keeping acceleration scheme 1
> > [ 523.039] (**) mouse: (accel) acceleration profile 0
> > [ 523.039] (**) mouse: (accel) acceleration factor: 2.000
> > [ 523.039] (**) mouse: (accel) acceleration threshold: 4
> > [ 523.045] (II) config/hal: Adding input device hotkey
> > 
> > 
> > in both cases is the the touchpad avail and a extern USB mouse connected. 
> > the /dev/mouse dev link is in both BE targeted to 
> > /devices/pseudo/cons@0:mouse
> > 
> > 
> Still no luck with the latest hipster on my laptop:
> 
> scanpci:
> pci bus 0x cardnum 0x00 function 0x00: vendor 0x8086 device 0x1604
>  Intel Corporation Broadwell-U Host Bridge -OPI
> 
> pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x1616
>  Intel Corporation HD Graphics 5500
> 
> pci bus 0x cardnum 0x03 function 0x00: vendor 0x8086 device 0x160c
>  Intel Corporation Broadwell-U Audio Controller
> 
> pci bus 0x cardnum 0x14 function 0x00: vendor 0x8086 device 0x9cb1
>  Intel Corporation Wildcat Point-LP USB xHCI Controller
> 
> pci bus 0x cardnum 0x16 function 0x00: vendor 0x8086 device 0x9cba
>  Intel Corporation Wildcat Point-LP MEI Controller #1
> 
> pci bus 0x cardnum 0x1b function 0x00: vendor 0x8086 device 0x9ca0
>  Intel Corporation Wildcat Point-LP High Definition Audio Controller
> 
> pci bus 0x cardnum 0x1c function 0x00: vendor 0x8086 device 0x9c90
>  Intel Corporation Wildcat Point-LP PCI Express Root Port #1
> 
> pci bus 0x cardnum 0x1c function 0x02: vendor 0x8086 device 0x9c94
>  Intel Corporation Wildcat Point-LP PCI Express Root Port #3
> 
> pci bus 0x0002 cardnum 0x00 function 0x00: vendor 0x10ec device 0x8168
>  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit 
> Ethernet Controller
> 
> pci bus 0x cardnum 0x1c function 0x03: vendor 0x8086 device 0x9c96
>  Intel Corporation Wildcat Point-LP PCI Express Root Port #4
> 
> pci bus 0x0003 cardnum 0x00 

Re: [oi-dev] Openindiana on Laptop: touchpad not working

2019-06-17 Thread Carsten Grzemba via oi-dev


On 23.05.19 08:34, Carsten Grzemba via oi-dev   wrote: 
> 
> I compared the Xorg log:
> 
> in the working log the mouse driver is loaded on PS/s mouse on /dev/mouse:
> 
> [ 38.008] (II) LoadModule: "mouse"
> [ 38.008] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so
> [ 38.012] (II) Module mouse: vendor="X.Org Foundation"
> [ 38.012] compiled for 1.19.5, module version = 1.9.2
> [ 38.012] Module class: X.Org XInput Driver
> [ 38.012] ABI class: X.Org XInput driver, version 24.1
> [ 38.012] (II) Using input driver 'mouse' for 'PS/2 Port for PS/2-style Mice'
> [ 38.012] (**) PS/2 Port for PS/2-style Mice: always reports core events
> [ 38.012] (**) Option "Device" "/dev/mouse"
> [ 38.012] (II) PS/2 Port for PS/2-style Mice: Setting Device option to 
> "/dev/mouse"
> [ 38.014] (==) PS/2 Port for PS/2-style Mice: Protocol: "VUID"
> [ 38.014] (**) PS/2 Port for PS/2-style Mice: always reports core events
> [ 38.014] (**) Option "Device" "/dev/mouse"
> [ 38.014] (==) PS/2 Port for PS/2-style Mice: Emulate3Buttons, 
> Emulate3Timeout: 50
> [ 38.014] (**) PS/2 Port for PS/2-style Mice: ZAxisMapping: buttons 4 and 5
> [ 38.014] (**) PS/2 Port for PS/2-style Mice: Buttons: 9
> [ 38.014] (**) Option "config_info" 
> "hal:/org/freedesktop/Hal/devices/pci_0_0/isa_1f/i8042_1_60/mouse_1_0_logicaldev_input"
> [ 38.014] (II) XINPUT: Adding extended input device "PS/2 Port for PS/2-style 
> Mice" (type: MOUSE, id 6)
> [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) keeping acceleration 
> scheme 1
> [ 38.014] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration profile 0
> [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration factor: 
> 2.000
> [ 38.015] (**) PS/2 Port for PS/2-style Mice: (accel) acceleration threshold: 
> 4
> 
> and the not working on the generic USB device /dev/usb/hid1:
> 
> [ 523.036] (II) Loading /usr/lib/xorg/modules/input/amd64/mouse_drv.so
> [ 523.036] (II) Module mouse: vendor="X.Org Foundation"
> [ 523.036] compiled for 1.19.5, module version = 1.9.2
> [ 523.036] Module class: X.Org XInput Driver
> [ 523.037] ABI class: X.Org XInput driver, version 24.1
> [ 523.037] (II) Using input driver 'mouse' for 'mouse'
> [ 523.037] (**) mouse: always reports core events
> [ 523.037] (**) Option "Protocol" "VUID"
> [ 523.037] (**) Option "Device" "/dev/usb/hid1"
> [ 523.037] (**) Option "StreamsModule" "usbms"
> [ 523.039] (**) mouse: Protocol: "VUID"
> [ 523.039] (**) mouse: always reports core events
> [ 523.039] (==) mouse: Emulate3Buttons, Emulate3Timeout: 50
> [ 523.039] (**) mouse: ZAxisMapping: buttons 4 and 5
> [ 523.039] (**) mouse: Buttons: 9
> [ 523.039] (**) Option "config_info" 
> "hal:/org/freedesktop/Hal/devices/pci_0_0/pci1025_1019_14/device_4/mouse_1_if1_4_logicaldev_input"
> [ 523.039] (II) XINPUT: Adding extended input device "mouse" (type: MOUSE, id 
> 6)
> [ 523.039] (**) mouse: (accel) keeping acceleration scheme 1
> [ 523.039] (**) mouse: (accel) acceleration profile 0
> [ 523.039] (**) mouse: (accel) acceleration factor: 2.000
> [ 523.039] (**) mouse: (accel) acceleration threshold: 4
> [ 523.045] (II) config/hal: Adding input device hotkey
> 
> 
> in both cases is the the touchpad avail and a extern USB mouse connected. the 
> /dev/mouse dev link is in both BE targeted to /devices/pseudo/cons@0:mouse
> 
> 
Still no luck with the latest hipster on my laptop:

scanpci:
pci bus 0x cardnum 0x00 function 0x00: vendor 0x8086 device 0x1604
 Intel Corporation Broadwell-U Host Bridge -OPI

pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x1616
 Intel Corporation HD Graphics 5500

pci bus 0x cardnum 0x03 function 0x00: vendor 0x8086 device 0x160c
 Intel Corporation Broadwell-U Audio Controller

pci bus 0x cardnum 0x14 function 0x00: vendor 0x8086 device 0x9cb1
 Intel Corporation Wildcat Point-LP USB xHCI Controller

pci bus 0x cardnum 0x16 function 0x00: vendor 0x8086 device 0x9cba
 Intel Corporation Wildcat Point-LP MEI Controller #1

pci bus 0x cardnum 0x1b function 0x00: vendor 0x8086 device 0x9ca0
 Intel Corporation Wildcat Point-LP High Definition Audio Controller

pci bus 0x cardnum 0x1c function 0x00: vendor 0x8086 device 0x9c90
 Intel Corporation Wildcat Point-LP PCI Express Root Port #1

pci bus 0x cardnum 0x1c function 0x02: vendor 0x8086 device 0x9c94
 Intel Corporation Wildcat Point-LP PCI Express Root Port #3

pci bus 0x0002 cardnum 0x00 function 0x00: vendor 0x10ec device 0x8168
 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet 
Controller

pci bus 0x cardnum 0x1c function 0x03: vendor 0x8086 device 0x9c96
 Intel Corporation Wildcat Point-LP PCI Express Root Port #4

pci bus 0x0003 cardnum 0x00 function 0x00: vendor 0x8086 device 0x095a
 Intel Corporation Wireless 7265

pci bus 0x cardnum 0x1c function 0x04: vendor 0x8086 device 0x9c98
 Intel Corporation Wildcat Point-LP PCI Express Root Port #5

pci bus 0x0004 cardnum 0x00 function 0x00: vendor 0x10de device