Re: asmc driver patch merge request

[Adrian Chadd]

this looks fine to me. what's with the whitespace changes?



-a


On 15 February 2017 at 19:27, Johannes Lundberg  wrote:
> Hi
>
> This patch adds support for MacBook Pro 11,2 to asmc.
>
> The other day I tried patching my old
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214836
>
> submission and discovered it did not apply at all anymore. I uploaded an
> updated patch that should apply cleanly to HEAD.
>
> Someone got time to merge this while it's fresh?
>
> Thanks!
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

asmc driver patch merge request

[Johannes Lundberg]

Hi

This patch adds support for MacBook Pro 11,2 to asmc.

The other day I tried patching my old

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214836

submission and discovered it did not apply at all anymore. I uploaded an
updated patch that should apply cleanly to HEAD.

Someone got time to merge this while it's fresh?

Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: basic evdev setup

[Vladimir Kondratyev]

Hi, Andriy

I can add my 2 cents to Oleksander`s

1. If xf86-input-keyboard is not used as primary keyboard driver, patch 
[1] should be applied to xorg-server to prevent ttyv8<->xorg frame 
buffers interference
2. It`s also worth trying one of PR/196678 patches to xorg devd 
configuration backend [2]
3. To see events going through evdev interface, evemu-record utility 
from evemu package [3] can be used.


[1] https://reviews.freebsd.org/differential/changeset/?ref=218662
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678
[3] https://www.freedesktop.org/software/evemu/

1, 2 and 3 was collected together at https://reviews.freebsd.org/D7588 
but this review is somewhat outdated now.



On 2017-02-16 00:57, Oleksandr Tymoshenko wrote:

Andriy Gapon (a...@freebsd.org) wrote:


Oleksandr,

at the moment the documentation for evdev on FreeBSD is very scarce, 
even if we

talk about wiki pages, informal howto-s or blog posts.
So, I would like to ask your help for a very basic evdev test setup.

All input devices I have are standard keyboard and a mouse with some 
extra keys.
I would like to be able to use the keyboard and the mouse as usual 
when in the
console.  And I would like to be able to use the extra mouse keys in 
X.


What steps should I take to achieve that?
I already evdev + EVDEV_SUPPORT on the kernel side in addition to the 
regular

keyboard and mouse drivers (atkbdc + ums).
I have also installed xf86-input-evdev.

Do I need any additional kernel evedev configuration via sysctl?
What should I add to xorg configuration to enable evdev for X?


* Adding Vladimir Kondratyev to Cc since he's contributed evdev patch

Hi Andriy,

evdev works in parallel with standard input system, so you don't
have to worry about console input support.

Current evdev implementation uses following devices as a source
of input events: ukbd(4), ums(4), atkbd(4), kbdmux(4), sysmouse(4)

As you see three of them are actual hardware and two of them are
virtual aggregating devices. You can enable/disable particular
sources using kern.evdev.rcpt_mask sysctl. There are four controlling
bits to enable/disable driver as a source of events:
bit 0: is set enables sysmouse
bit 1: is set enables kbdmux
bit 2: is set enables ums
bit 3: is set enables atkbd, ukbd

By default sysmouse and kbdmux are enabled. Sysmouse requires
moused to work, so make sure that moused is running on your system.

In your Xorg config you'll need something like this:

Section "InputDevice"
  Identifier "Mouse0"
  Driver "evdev"
  Option "Device" "/dev/input/event0"
EndSection

Section "InputDevice"
  Identifier "Keyboard0"
  Driver "evdev"
  Option "Device" "/dev/input/event1"
EndSection

I didn't test Xorg thoroughly so there might be some undiscovered
bugs. My target use case was Qt in EGLFS mode. If you have any
questions or bugreports - I'll be glad to answer them

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: basic evdev setup

[Oleksandr Tymoshenko]

Andriy Gapon (a...@freebsd.org) wrote:
> 
> Oleksandr,
> 
> at the moment the documentation for evdev on FreeBSD is very scarce, even if 
> we
> talk about wiki pages, informal howto-s or blog posts.
> So, I would like to ask your help for a very basic evdev test setup.
> 
> All input devices I have are standard keyboard and a mouse with some extra 
> keys.
> I would like to be able to use the keyboard and the mouse as usual when in the
> console.  And I would like to be able to use the extra mouse keys in X.
> 
> What steps should I take to achieve that?
> I already evdev + EVDEV_SUPPORT on the kernel side in addition to the regular
> keyboard and mouse drivers (atkbdc + ums).
> I have also installed xf86-input-evdev.
> 
> Do I need any additional kernel evedev configuration via sysctl?
> What should I add to xorg configuration to enable evdev for X?

* Adding Vladimir Kondratyev to Cc since he's contributed evdev patch

Hi Andriy,

evdev works in parallel with standard input system, so you don't
have to worry about console input support. 

Current evdev implementation uses following devices as a source
of input events: ukbd(4), ums(4), atkbd(4), kbdmux(4), sysmouse(4)

As you see three of them are actual hardware and two of them are
virtual aggregating devices. You can enable/disable particular
sources using kern.evdev.rcpt_mask sysctl. There are four controlling
bits to enable/disable driver as a source of events:
bit 0: is set enables sysmouse
bit 1: is set enables kbdmux
bit 2: is set enables ums
bit 3: is set enables atkbd, ukbd

By default sysmouse and kbdmux are enabled. Sysmouse requires
moused to work, so make sure that moused is running on your system.

In your Xorg config you'll need something like this:

Section "InputDevice"
  Identifier "Mouse0"
  Driver "evdev"
  Option "Device" "/dev/input/event0"
EndSection

Section "InputDevice"
  Identifier "Keyboard0"
  Driver "evdev"
  Option "Device" "/dev/input/event1"
EndSection

I didn't test Xorg thoroughly so there might be some undiscovered
bugs. My target use case was Qt in EGLFS mode. If you have any
questions or bugreports - I'll be glad to answer them

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: removing SVR4 binary compatibilty layer

[Peter Jeremy]

On 2017-Feb-14 10:32:32 -0800, Gleb Smirnoff  wrote:
>  After some discussion on svn mailing list [1], there is intention
>to remove SVR4 binary compatibilty layer from FreeBSD head, meaning
>that FreeBSD 12.0-RELEASE, available in couple of years would
>be shipped without it. There is no intention of merge of the removal.
>The stable@ mailing list added for wider audience.

Can I suggest that we put some warnings into the SVr4 image activation
code and MFC that to at least 11 to try and smoke out anyone who might
actually be using it.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

basic evdev setup

[Andriy Gapon]

Oleksandr,

at the moment the documentation for evdev on FreeBSD is very scarce, even if we
talk about wiki pages, informal howto-s or blog posts.
So, I would like to ask your help for a very basic evdev test setup.

All input devices I have are standard keyboard and a mouse with some extra keys.
I would like to be able to use the keyboard and the mouse as usual when in the
console.  And I would like to be able to use the extra mouse keys in X.

What steps should I take to achieve that?
I already evdev + EVDEV_SUPPORT on the kernel side in addition to the regular
keyboard and mouse drivers (atkbdc + ums).
I have also installed xf86-input-evdev.

Do I need any additional kernel evedev configuration via sysctl?
What should I add to xorg configuration to enable evdev for X?

Thank you!
-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: removing SVR4 binary compatibilty layer

[mokhi]

Well, I'd like to offer help keeping it (because on a personal
opinion, I'd like being compatible `:-D).
But the reasons are pretty reasonable and convincing :-).
I have no more objections against removing it when security risks involves.

--
Best wishes, MMokhi.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: removing SVR4 binary compatibilty layer

[Poul-Henning Kamp]

In message <20170215081430.gc58...@freebsd.org>, Gleb Smirnoff writes:

>Well, we all "maintain" it, meaning that we keep it compilable. However,
>I'm sure that no one checks the functionality. There are no regression
>tests, and seems to be no users.

And probably nobody ever bothered to check the code comprehensively
for security risks...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: removing SVR4 binary compatibilty layer

[Gleb Smirnoff]

On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote:
m> Is this removing is because no-interest on maintaining it?
m> 
m> If it helps, I am working to use the `kern_* instead sys_*` as
m> mentioned patch in that discussion suggests for svr4, if this helps.

Well, we all "maintain" it, meaning that we keep it compilable. However,
I'm sure that no one checks the functionality. There are no regression
tests, and seems to be no users. I recently found that if you run
GENERIC and 'kldload svr4.ko', the socket layer compatibility will
be broken, since SVR4 requires COMPAT_OLDSOCK. And that has been for
decades, and no one notices that. I bet there are simply no users.

Towing this piece of code into the future is just a waste of time.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"